Skip to content

Commit

Permalink
added git and url approaches (#117)
Browse files Browse the repository at this point in the history
  • Loading branch information
@hellt
hellt authored Nov 21, 2023
1 parent 29ae25b commit 1e274ea
Show file tree
Hide file tree
Showing 2 changed files with 147 additions and 57 deletions.
199 changes: 142 additions & 57 deletions docs/blog/posts/2023/instant-srl-labs.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,103 +9,188 @@ authors:

# Instant SR Linux Labs

With [containerlab](https://containerlab.dev) we already made it possible to quickly launch labs on demand with just a few commands. You would need to clone a repository with the lab and then call `containerlab deploy` to start the lab.
[Containerlab](https://containerlab.dev) already made it possible to quickly launch labs on demand with just a few commands. You would need to clone a repository with the lab and then call `containerlab deploy` to start the lab.

Simple enough, but quite often you want to run this simple SR Linux lab to test something quickly using a very basic topology. At times like this it is cumbersome to find and clone the repository and then call `deploy` command. Can we make it even more simple? Yes, we can!

<!-- more -->

If we have two steps to start a lab (cloning and calling `deploy`) we can combine them into one step by using two different approaches:

1. curl the lab definition file from the repository and pipe it to `containerlab deploy` command
2. provide the github URL to the `deploy` command and [let it do the cloning](https://containerlab.dev/cmd/deploy/#remote-topology-files) for us
1. provide HTTP(S) URL to the deploy command and let containerlab fetch the clab file and deploy from it
1. provide GitHub/GitLab URL to the `deploy` command and [let containerlab clone the repo](https://containerlab.dev/cmd/deploy/#remote-topology-files) for us and deploy from it
2. curl the lab definition file from the repository and pipe it to `containerlab deploy` command

Both approaches are equally simple and can be used interchangeably, but they have some differences in the way they work. We will cover the `curl` approach as it is more akin to the goals of this post - which is to quickly start a tiny lab with SR Linux.
These approaches are equally simple, but they have quite distinct powers and limitations. Let's explore them in more detail.

## Using curl to deploy a lab
/// warning
These features require [containerlab v0.48.2](https://containerlab.dev/install/) or later.
///

The workflow boils down to getting the lab definition file contents from a remote location and pipe it to `containerlab deploy` command. Since most labs are stored in git repositories, using `curl` is likely the most convenient way to get the file contents.
## Using HTTP(S) URL

```bash title="using stdin to deploy a lab"
curl some.url | containerlab deploy -c -t -
Deploying a lab from a remote HTTP(S) URL is the simplest way to get a lab up and running. All you need to do is to provide the URL to the `deploy` command and containerlab will fetch the file and deploy from it.

```bash title="Deploying a lab from a remote URL"
sudo clab deploy -c -t https://srlinux.dev/clab-srl
```

Since we wanted to let our users deploy basic SR Linux labs using a memorizable command, we created the following topology files hosted in the containerlab repository:
<div class="embed-result">
```
INFO[0000] Containerlab v0.48.2 started
INFO[0000] Parsing & checking topology file: topo-2790519753.clab.yml
INFO[0000] Removing /root/srl-labs/learn-srlinux/clab-srl directory...
INFO[0000] Creating lab directory: /root/srl-labs/learn-srlinux/clab-srl
INFO[0000] Creating container: "srl"
INFO[0013] Adding ssh config for containerlab nodes
+---+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| # | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+---+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| 1 | srl | ee079defad8e | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
+---+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
```
</div>

=== "Single SR Linux node"
This lab defines a single SR Linux node named `clab-srl`. This lab is meant for users who just want to quickly test something on a single SR Linux node.
When deploying a clab file from a remote URL containerlab will download the clab file to a temporary directory - `/tmp/.clab` - and then perform a deploy command using the downloaded file. The temporary file will be deleted when the lab is destroyed with the cleanup flag provided.

```yaml
--8<-- "https://raw.githubusercontent.com/srl-labs/containerlab/main/lab-examples/srl-quickstart/srl01.clab.yml"
```
/// details | Where exactly is my topology file?
The lab file is downloaded to a temporary location as can be verified with the `containerlab inspect --all` command:

```note
$ containerlab inspect --all
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| # | Topo Path | Lab Name | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| 1 | ../../../tmp/.clab/topo-288756812.clab.yml | srl | srl | 6b5cad8a221d | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
```

=== "Two SR Linux nodes"
This lab defines two SR Linux nodes named `clab-srl1` and `clab-srl2` connected with two links. In this lab users can test protocol interactions between two SR Linux nodes.
///

```yaml
--8<-- "https://raw.githubusercontent.com/srl-labs/containerlab/main/lab-examples/srl-quickstart/srl02.clab.yml"
```
Using HTTP-based lab deployment technique opens up a door to quickly deploy simple SR Linux labs with a single **mermorizable** command. This is handy when you need to quickly test something on SR Linux or demonstrate a feature to a colleague.

And here is how you can deploy an Single node SR Linux lab with an easy to remember command:
### Single node SR Linux lab

```{.bash .no-select}
curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -
Here is the lab definition file that we used in the above example:

```yaml
--8<-- "https://raw.githubusercontent.com/srl-labs/containerlab/main/lab-examples/srl-quickstart/srl01.clab.yml"
```

As you can see, it is a simple single-node lab with SR Linux node named `srl`. This lab is meant for users who just want to quickly test something on a single SR Linux node and doesn't require any networking part to be configured.

The command can even be shortened further to:

```
sudo clab dep -c -t srlinux.dev/clab-srl
```

Once the lab is deployed you can type in `ssh srl` and get access to the SR Linux shell. Easy!

#### Parametrization

An attentive reader might have noticed that the lab definition file contains some environment variables. They allow to parametrize the lab definition file and change the SR Linux version or the type of the node.

If you deploy the commands as we did a few moments ago, the lab will be deployed with the default parameters:

* `ghcr.io/nokia/srlinux:latest` image will be used
* `ixrd3l` type will be used
* lab prefix is removed

If you wish to change the SR Linux version or the type, you can do so by providing the env vars to the `containerlab` command:

```bash title="Deploying a lab with a different image and type"
SRL_VERSION=23.10.1 SRL_TYPE=ixrd2 \
sudo containerlab deploy -c -t srlinux.dev/clab-srl
```

Since the default value for the lab prefix is an empty string, the node name (as well as container name) will be just `srl`. This makes it easy to connect to the node with `ssh srl` command, but if you want to deploy multiple labs with the same topology, you will need to change the prefix to avoid name collisions. Simply set `CLAB_PREFIX` variable to any value you want.

### Two-node SR Linux lab

In exactly the same spirit as the single-node lab, we thought it would be cool to have two SR Linux nodes connected back-to-back together. This lab can be deployed as:

```
sudo clab deploy -c -t https://srlinux.dev/clab-srl2
```

<div class="embed-result">
```bash
INFO[0000] Containerlab v0.47.0 started
INFO[0000] Parsing & checking topology file: topo-4226352936.clab.yml
INFO[0000] Removing /root/srl-labs/learn-srlinux/clab-clab directory...
INFO[0000] Creating docker network: Name="clab", IPv4Subnet="172.20.20.0/24", IPv6Subnet="2001:172:20:20::/64", MTU='֪'
INFO[0000] Creating lab directory: /root/srl-labs/learn-srlinux/clab-clab
INFO[0000] Creating container: "srl"
INFO[0001] Running postdeploy actions for Nokia SR Linux 'srl' node
INFO[0014] Adding containerlab host entries to /etc/hosts file
INFO[0014] Adding ssh config for containerlab nodes
```
+---+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| # | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+---+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| 1 | srl | 6b5cad8a221d | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
| 1 | srl1 | 483cb7209697 | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.4/24 | 2001:172:20:20::4/64 |
| 2 | srl2 | 936647611ade | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.3/24 | 2001:172:20:20::3/64 |
+---+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
```
</div>

??? "Where is my topology downloaded to?"
The lab file is downloaded to a temporary location as can be verified with the `containerlab inspect --all` command:
This lab deploys nodes `srl1` and `srl2` and provides the same environment variables to parametrize the lab definition file.

### Limitations

The limitations of this approach is that clab file can not have external files used in the lab definition. For example, if you have a lab definition that relies on bind mounting of local files, you will not be able to deploy it from a remote URL. But thankfully we have a way to deploy labs from git repositories :wink:

## Using Git URL

Containerlab [added support](https://containerlab.dev/cmd/deploy/#git) for GitHub/GitLab URLs provided to the `deploy` command. The linked documentation article explains how different flavors of git URLs can be used to deploy labs from managed git repositories.

What is important for us here, is that we can now deploy full-blown labs by simply copying URL of the lab repository from the browser. Here is how it works:

<div class="iframe-container">
<iframe width="100%" src="https://www.youtube.com/embed/0QlUZsJGQDo" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

Because containerlab will clone the repository, the limitations of the previous approach are not applicable here. Your repository will be cloned in its entirety and therefore you will have access to all the files that are part of the repository. For example, deploying the SR Linux Streaming Telemetry Lab is as simple as:

```note
$ containerlab inspect --all
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| # | Topo Path | Lab Name | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| 1 | ../../../tmp/.clab/topo-288756812.clab.yml | srl | srl | 6b5cad8a221d | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
```
```bash title="Deploying a lab from a git repository"
sudo clab dep -c -t https://github.com/srl-labs/srl-telemetry-lab
```

Now you can type in `ssh srl` and get access to the SR Linux shell. Easy!
<div class="embed-result">
```
+----+------------+--------------+---------------------------------+---------------+---------+-----------------+--------------+
| # | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+----+------------+--------------+---------------------------------+---------------+---------+-----------------+--------------+
| 1 | client1 | 95ae7aa52c27 | ghcr.io/hellt/network-multitool | linux | running | 172.80.80.31/24 | N/A |
| 2 | client2 | 3996c8850794 | ghcr.io/hellt/network-multitool | linux | running | 172.80.80.32/24 | N/A |
| 3 | client3 | a3312bc21e21 | ghcr.io/hellt/network-multitool | linux | running | 172.80.80.33/24 | N/A |
| 4 | gnmic | 7e0262a63604 | ghcr.io/openconfig/gnmic:0.33.0 | linux | running | 172.80.80.41/24 | N/A |
| 5 | grafana | 31b1419f9d92 | grafana/grafana:10.2.1 | linux | running | 172.80.80.43/24 | N/A |
| 6 | leaf1 | 954283a965b6 | ghcr.io/nokia/srlinux:23.10.1 | nokia_srlinux | running | 172.80.80.11/24 | N/A |
| 7 | leaf2 | b5fe74887300 | ghcr.io/nokia/srlinux:23.10.1 | nokia_srlinux | running | 172.80.80.12/24 | N/A |
| 8 | leaf3 | 54f0d0592f12 | ghcr.io/nokia/srlinux:23.10.1 | nokia_srlinux | running | 172.80.80.13/24 | N/A |
| 9 | loki | 64735db32d5e | grafana/loki:2.9.2 | linux | running | 172.80.80.46/24 | N/A |
| 10 | prometheus | 28d62ea18df3 | prom/prometheus:v2.47.2 | linux | running | 172.80.80.42/24 | N/A |
| 11 | promtail | 6a5526bca5d3 | grafana/promtail:2.9.2 | linux | running | 172.80.80.45/24 | N/A |
| 12 | spine1 | 03cab687a6a9 | ghcr.io/nokia/srlinux:23.10.1 | nokia_srlinux | running | 172.80.80.21/24 | N/A |
| 13 | spine2 | b237260b25bf | ghcr.io/nokia/srlinux:23.10.1 | nokia_srlinux | running | 172.80.80.22/24 | N/A |
| 14 | syslog | 13188f89a169 | linuxserver/syslog-ng:4.1.1 | linux | running | 172.80.80.44/24 | N/A |
+----+------------+--------------+---------------------------------+---------------+---------+-----------------+--------------+
```
</div>

In the same spirit you can deploy a two-node SR Linux lab with a similar command (watch out for the `clab-srl2` name in the URL):
/// tip | Did you know?
For GitHub-hosted repos you can shrink the URL down to just as `user/repo`, for example:

```{.bash .no-select}
curl -sL srlinux.dev/clab-srl2 | containerlab deploy -c -t -
```
sudo clab dep -c -t srl-labs/srl-telemetry-lab
```

## Parametrizing the lab
///

If you run the above commands as is, the labs will be deployed with the default parameters:
## Using `curl`

* `ghcr.io/nokia/srlinux:latest` image will be used
* `ixrd3l` type will be used
And then lastly, you can use `curl`, `wget` or any other HTTP client to fetch the clab file and pipe it to `containerlab deploy` command. That way you can provide custom proxies to the HTTP client if required.

If you wish to change the SR Linux version or the type, you can do so by providing the env vars to the `containerlab` command:
For example, deploying the same single-node SR Linux lab with `curl` can be done as:

```bash title="Deploying a lab with a different image and type"
curl -sL srlinux.dev/clab-srl | \
SRL_VERSION=23.3.2 SRL_TYPE=ixrd2 \
containerlab deploy -c -t -
```bash title="Deploying a lab from a remote URL with curl"
curl -sL srlinux.dev/clab-srl | sudo clab deploy -c -t -
```

## Summary

In this post we showed how to quickly deploy a single or two-node SR Linux lab using a simple command. Anywhere you are you can just type in `curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -` and get a lab up and running in a matter of seconds.
In this post we showed different ways to quickly deploy a single or two-node SR Linux lab using a simple, memorizable commands. Anywhere you are, you can just type in `curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -` and get a lab up and running in a matter of seconds.

We identified which limitations deployment from a remote URL has and how to overcome them by deploying labs from git repositories. Giving the flexibility in options whilst keeping the simplicity of the deployment process is what makes containerlab a great tool for SR Linux labs in particular and networking labs in general.
5 changes: 5 additions & 0 deletions mkdocs.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -264,6 +264,11 @@ markdown_extensions:
format: !!python/name:pymdownx.superfences.fence_code_format
- pymdownx.tabbed:
alternate_style: true
- pymdownx.blocks.tab:
alternate_style: true
- pymdownx.blocks.admonition
- pymdownx.blocks.definition
- pymdownx.blocks.details
- pymdownx.tasklist:
custom_checkbox: true
- pymdownx.tilde
Expand Down

0 comments on commit 1e274ea

Please sign in to comment.