Skip to content

Commit

Permalink
build and package docs
Browse files Browse the repository at this point in the history
  • Loading branch information
hellt committed Sep 18, 2024
1 parent 0d3a8fd commit 8c1f2fd
Show file tree
Hide file tree
Showing 4 changed files with 83 additions and 2 deletions.
2 changes: 1 addition & 1 deletion docs/ndk/guide/agent-install-and-ops.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ The agent installation procedure can be carried out in different ways:
The first two options are easy to execute, but they are a bit more involved as the installers need to maintain the remote paths for the copy commands. When using the `deb` option, though, it becomes less cumbersome to install the package. All the installers deal with is a single `.deb` file and a copy command.
Of course, the build process of the `deb` package is still required, and we would like to explain this process in detail.

## Deb/RPM package
## Packaging the NDK application

/// admonition | Deb or RPM?
Prior to 24.3 release SR Linux used an rpm-based base Linux image, therefore the RPM package was used to distribute the NDK applications.
Expand Down
38 changes: 38 additions & 0 deletions docs/ndk/guide/dev/go/build-and-package.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Building and packaging the application

The local [`run.sh`][run-sh] script has convenience functions to build, compress and package the application. For example, to build a development package one can simply run:

```bash
./run.sh package
```

This function will build, compress and package the application in a deb package in your `./build` directory. You can then copy this file over to an SR Linux container or hardware system and try it out.

/// admonition | Packaging with nFPM
The packaging step is explained in detail in [Packaging the NDK app section](../../agent-install-and-ops.md#packaging-the-ndk-application).
///

While using the `run.sh` script is fine for a quick local development, you would rather have a build pipeline that can use something like [Goreleaser][goreleaser] and build, package and push the application in a single step.

The greeter app repo uses [Goreleaser][goreleaser] to build, package and push the application to a free package repository. Checkout the GitHub actions workflow defined in the [`cicd.yml`][cicd-wf] file for more details as well as the [`goreleaser.yml`][goreleaser-yml] file for the Goreleaser configuration.

## Try greeter

Once the application package is published in our package repository, containerlab users can install it on their SR Linux system:

```srl
--{ running }--[ ]--
A:srl# bash sudo apt update && sudo apt install -y ndk-greeter-go
```

Once the package is installed, reload your app manager and try configuring the greeter app:

```srl
--{ running }--[ ]--
A:srl# /tools system app-management application app_mgr reload
```

[goreleaser]: https://goreleaser.com/
[run-sh]: https://github.com/srl-labs/ndk-greeter-go/blob/use-bond-agent/run.sh
[goreleaser-yml]: https://github.com/srl-labs/ndk-greeter-go/blob/use-bond-agent/goreleaser.yml
[cicd-wf]: https://github.com/srl-labs/ndk-greeter-go/blob/use-bond-agent/.github/workflows/cicd.yml
44 changes: 43 additions & 1 deletion docs/ndk/guide/dev/go/with-bond/app.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,48 @@ As you can see, the logic is straightforwards, but it is a good example of how t

As we already mentioned, the `greeter` app uses two data points to create the greeting message. The first one is the `name` a user has configured the app with. The second one is the last-booted-time from the SR Linux state. Our app gets the `name` from the configuration, and the last-booted-time we need to fetch from the SR Linux state as this is not part of the app's config.

An application developer can choose different ways to fetch data from the SR Linux, but Bond provides a gNMI client that can be used to fetch the data.
An application developer can choose different ways to fetch data from SR Linux, but since Bond already provides a gNMI client, it might be the easiest way to fetch the data.

```{.go title="greeter/app.go"}
--8<-- "https://raw.githubusercontent.com/srl-labs/ndk-greeter-go/use-bond-agent/greeter/app.go:get-uptime"
```

Using the `bond.NewGetRequest` we construct a gNMI Get request by providing a path for the `last-booted` state data. Then `a.NDKAgent.GetWithGNMI(getReq)` sends the request to the SR Linux and receives the response.
All we have to do is parse the response and extract the value.

Now we have all ingredients to compose the greeting message, which we save in the application' `configState` structure:

```go
a.configState.Greeting = "👋 Hi " + a.configState.Name +
", SR Linux was last booted at " + uptime
```

## Posting app's state

Ok, we've completed 90% of our greeter application. The last 10% is sending the computed greeting value back to SR Linux. This is what we call "updating the application state".

Right now the greeting message is nothing more than a string value in the application's `configState` structure. But SR Linux doesn't know anything about it, only application does. Let's fix it.

Applications can post their state to SR Linux via NDK, this way the application state becomes visible to SR Linux and therefore the data can be fetched through any of the available interfaces. The greeter app has the `updateState` function defined that does exactly that.

```{.go title="greeter/state.go"}
--8<-- "https://raw.githubusercontent.com/srl-labs/ndk-greeter-go/use-bond-agent/greeter/state.go:update-state"
```

The updateState logic is rather straightforward. We have to convert the application's `configState` structure into a json-serialized byte slice and then use Bond's `UpdateState` function to post it to SR Linux.
We provide the application's YANG path (`AppRoot`) and the string formatted json blob of the application's `configState` structure.

This will populate the application's state in the SR Linux state and will become available for query over any of the supported management interfaces.

## Summary

That's it! We have successfully created a simple application that uses SR Linux's [NetOps Development Kit](https://ndk.srlinux.dev) and [srl-labs/bond][bond-repo] library that assists in the development process.

We hope that this guide has helped you understand the high-level steps every application needs to take out in order successfully use NDK to register itself with SR Linux, get its configuration, and update its state.

Now let's see how we can package our app and make it installable on SR Linux.

:octicons-arrow-right-24: [Building and packaging the application](../build-and-package.md)

[bond-repo]: https://github.com/srl-labs/bond
[main-go]: https://github.com/srl-labs/ndk-greeter-go/blob/use-bond-agent/main.go
1 change: 1 addition & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,7 @@ nav:
- Main function: ndk/guide/dev/go/with-bond/main.md
- Bond agent: ndk/guide/dev/go/with-bond/bond.md
- Greeter app: ndk/guide/dev/go/with-bond/app.md
- Packaging: ndk/guide/dev/go/with-bond/package.md
- Logging: ndk/guide/dev/go/with-bond/logging.md
- The Hard Way:
- ndk/guide/dev/go/the-hard-way/index.md
Expand Down

0 comments on commit 8c1f2fd

Please sign in to comment.