This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
dagger/docs/use-cases/1211-go-docker-swarm.md
jffarge 9189b5cb20 use h2 title instead of h3 + fix code css
Signed-off-by: jffarge <jf@dagger.io>
2022-03-31 19:55:03 +02:00

122 lines
3.6 KiB
Markdown

---
slug: /1211/go-docker-swarm
displayed_sidebar: europa
---
# Go on Docker Swarm
![particubes.com](/img/use-cases/particubes.com.png)
[Particubes](https://particubes.com) is a platform dedicated to voxel games, which are games made out of little cubes, like Minecraft.
The team consists of 10 developers that like to keep things simple.
They write primarily Go & Lua, push to GitHub and use GitHub Actions for automation.
The production setup is a multi-node Docker Swarm cluster running on AWS.
The Particubes team chose Dagger for continuous deployment because it was the easiest way of integrating GitHub with Docker Swarm.
Every commit to the main branch goes straight to [docs.particubes.com](https://docs.particubes.com) via a Dagger pipeline that runs in GitHub Actions. Let us see how the Particubes Dagger plan fits together.
## Actions API
This is a high level overview of all actions in the Particubes docs Dagger plan:
![particubes flat plan](/img/use-cases/particubes-actions.png)
We can see all available actions in a Plan by running the following command:
```console
$ dagger do
Execute a dagger action.
Available Actions:
build Create a container image
clean Remove a container image
test Locally test a container image
deploy Deploy a container image
```
## Client API
Dagger actions usually need to interact with the host environment where the Dagger client runs. The Particubes' plan uses environment variables and the filesystem.
This is an overview of all client interactions for this plan:
![Client API](/img/use-cases/client-api.png)
This is what the above looks like in the Dagger plan config:
```cue file=../tests/use-cases/go-docker-swarm/client-api.cue.fragment
```
## The `build` Action
This is a more in-depth overview of the _build_ action and how it interacts with the client in the Particubes docs Dagger plan:
![build action](/img/use-cases/build-action.png)
This is what the above looks like in the Dagger plan config:
```cue file=../tests/use-cases/go-docker-swarm/build-action.cue.fragment
```
## Github Action integration
This is the GitHub Actions workflow config that invokes `dagger`, which in turn runs the full plan:
```yaml
name: Dagger/docs.particubes.com
on:
push:
branches: [master]
jobs:
deploy:
runs-on: ubuntu-latest
env:
GITHUB_SHA: ${{ github.sha }}
SSH_PRIVATE_KEY_DOCKER_SWARM: ${{ secrets.SSH_PRIVATE_KEY_DOCKER_SWARM }}
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Install Dagger
uses: dagger/dagger-action@v2
with:
install-only: true
- name: Dagger poject update
run: dagger project update
- name: Dagger do test
run: dagger do test --log-format plain
- name: Dagger do deploy
run: dagger do deploy --log-format plain
```
Since this is a Dagger pipeline, anyone on the team can run it locally with a single command:
```console
dagger do
```
This is the first step that enabled the Particubes team to have the same CI/CD experience everywhere.
## Full Particubes docs Dagger plan
This is the entire plan running on Particubes' CI:
```cue file=../tests/use-cases/go-docker-swarm/full/particubes.docs.cue
```
## What comes next ?
Particubes' team suggested that we create a `dev` action with _hot reload_, that way Dagger would even asbtract away the ramp-up experience when developing the doc
:::tip
The latest version of this pipeline can be found at [github.com/voxowl/particubes/pull/144](https://github.com/voxowl/particubes/blob/2af173596729929cfb7a7a1f78f1ec0d8b685e5e/lua-docs/docs.cue)
:::