proofreading

content/posts/08-build-your-own-docker-swarm-cluster-part-7/index.md

@@ -26,9 +26,7 @@ Of course, in a ~$30 cluster, forget about running a self-hosted GitLab, you wil
 
 You guess it, it's just an additional stack to run !
 
-Let's do `sudo mkdir /mnt/storage-pool/gitea`
-
-Then create a new `gitea` stack :
+Do `sudo mkdir /mnt/storage-pool/gitea` and create a new `gitea` stack :
 
 {{< highlight host="stack" file="gitea" >}}
 
@@ -146,21 +144,33 @@ Go to <https://registry.sw.dockerswarm.rocks> and use Traefik credentials. We ha
 
 ### Test our private registry
 
-Login into the `manager-01` server, do `docker login registry.sw.dockerswarm.rocks` and enter proper credentials. You should see *Login Succeeded*. Don't worry about the warning. Create the next Dockerfile somewhere :
+Create a Dockerfile sample file somewhere :
+
+{{< highlight host="manager-01" file="~/Dockerfile" >}}
 
 ```Dockerfile
 FROM alpine:latest
 RUN apk add --no-cache git
 ```
 
+{{< /highlight >}}
+
 Then build and push the image :
 
+{{< highlight host="manager-01" >}}
+
 ```sh
+# enter proper credentials
+docker login registry.sw.dockerswarm.rocks
+
+# build the image
 docker build -t alpinegit .
 docker tag alpinegit registry.sw.dockerswarm.rocks/alpinegit
 docker push registry.sw.dockerswarm.rocks/alpinegit
 ```
 
+{{< /highlight >}}
+
 Go back to above <https://registry.sw.dockerswarm.rocks>. You should see 1 new image !
 
 [![Docker registry](docker-registry.png)](docker-registry.png)
@@ -335,6 +345,8 @@ It will create a webhook inside repository settings, triggered on every code pus
 
 Now generate a new SSH key on `manager-01` :
 
+{{< highlight host="manager-01" >}}
+
 ```sh
 ssh-keygen -t ed25519 -C "admin@sw.dockerswarm.rocks"
 cat .ssh/id_ed25519 # the private key to set in swarm_ssh_key
@@ -342,6 +354,8 @@ cat .ssh/id_ed25519.pub # the public key to add just below
 echo "ssh-ed25519 AAAA... admin@sw.dockerswarm.rocks" | tee -a .ssh/authorized_keys
 ```
 
+{{< /highlight >}}
+
 Then configure the repository settings on Drone. Go to *Organization > Secrets* section and add some global secrets.
 
 | name                | description                                |
@@ -356,6 +370,8 @@ Then configure the repository settings on Drone. Go to *Organization > Secrets*
 
 For working, Drone needs a `.drone.yml` file in root of repository. This file will describe all steps of our build pipeline. Let's create and explain it :
 
+{{< highlight file=".drone.yml" >}}
+
 ```yml
 kind: pipeline
 type: docker
@@ -384,6 +400,8 @@ trigger:
     - pull_request
 ```
 
+{{< /highlight >}}
+
 It's just simple 2 steps :
 
 1. `build` : Here is the step for project dependencies import, compilation, testing, and code linting / formatting. This is a very basic project here, so we start with a simple building. The image `mcr.microsoft.com/dotnet/sdk:6.0` is the required docker image for proper .NET building. The publish command will generate a `publish` subdirectory.
@@ -391,6 +409,8 @@ It's just simple 2 steps :
 
 Next create the Dockerfile which will be used for `image` step :
 
+{{< highlight file="Dockerfile" >}}
+
 ```Dockerfile
 FROM mcr.microsoft.com/dotnet/aspnet:6.0
 RUN apt-get install -y tzdata
@@ -401,6 +421,8 @@ WORKDIR /app
 ENTRYPOINT ["dotnet", "my-weather-api.dll"]
 ```
 
+{{< /highlight >}}
+
 We use production suited .NET runtime image `mcr.microsoft.com/dotnet/aspnet:6.0`. Note as **WE MUST** do the simplest commands possible in order to have the lightest image layers, as it's the production image. All we have to do is to copy the final published binaries from above `build` drone step.
 
 Commit both above files and push to remote repo. Drone should be automatically triggered for building and activate the runner. The runner will clone the project and process all pipeline's steps.
@@ -457,6 +479,8 @@ Now we must be sure that the `runner-01` host can reach the `manager-01` server
 
 Now let's add a new `deploy` step inside `.drone.yml` into our pipeline for automatic deployment !
 
+{{< highlight file=".drone.yml" >}}
+
 ```yml
 #...
   - name: deploy
@@ -472,8 +496,12 @@ Now let's add a new `deploy` step inside `.drone.yml` into our pipeline for auto
 #...
 ```
 
+{{< /highlight >}}
+
 The as example edit `Program.cs` file and change next line :
 
+{{< highlight file="Program.cs" >}}
+
 ```cs
 builder.Services.AddSwaggerGen(c =>
 {
@@ -485,6 +513,8 @@ builder.Services.AddSwaggerGen(c =>
 });
 ```
 
+{{< /highlight >}}
+
 Push and back to your API, and the title and version should be automatically updated !
 
 [![Weather API](weather-api.png)](weather-api.png)

content/posts/09-build-your-own-docker-swarm-cluster-part-8/index.md

@@ -27,6 +27,8 @@ dotnet add package OpenTelemetry.Exporter.Jaeger --prerelease
 
 Then add automatic ASP.NET instrumentation and configure Jaeger exporter in `Program.cs` by adding following lines before `builder.Build()` :
 
+{{< highlight file="Program.cs" >}}
+
 ```cs
 using OpenTelemetry.Resources;
 using OpenTelemetry.Trace;
@@ -48,6 +50,8 @@ builder.Services.AddOpenTelemetryTracing(b => b
 //...
 ```
 
+{{< /highlight >}}
+
 Push the code and ensure all CI/CD workflow passes.
 
 Then edit the `weather` docker stack and configure Jaeger connection.
@@ -91,6 +95,8 @@ Let's get some automatic quality code metrics.
 
 On `manager-01` :
 
+{{< highlight host="manager-01" >}}
+
 ```sh
 sudo mkdir -p /mnt/storage-pool/sonar/data
 sudo mkdir -p /mnt/storage-pool/sonar/logs
@@ -101,6 +107,8 @@ echo "vm.max_map_count=262144" | tee /etc/sysctl.d/local.conf
 sudo service procps restart
 ```
 
+{{< /highlight >}}
+
 Create a `sonar` PostgresSQL database, and create a `sonar` stack :
 
 {{< highlight host="stack" file="sonar" >}}
@@ -174,6 +182,8 @@ Because running scanner manually is boring, let's integrate it in our favorite C
 
 Change the `build` step on `.drone.yml` file :
 
+{{< highlight file=".drone.yml" >}}
+
 ```yml
 #...
   - name: build
@@ -190,6 +200,8 @@ Change the `build` step on `.drone.yml` file :
 #...
 ```
 
+{{< /highlight >}}
+
 And voilà ! You should have automatic code analysis on every code push.
 
 {{< alert >}}
@@ -270,6 +282,8 @@ networks:
 
 First create a simple JS script as docker swarm *Config* named `k6_weather_test_01` through Portainer UI :
 
+{{< highlight host="config" file="k6_weather_test_01" >}}
+
 ```js
 import http from "k6/http";
 import { check } from "k6";
@@ -279,6 +293,8 @@ export default function () {
 }
 ```
 
+{{< /highlight >}}
+
 [![Portainer config k6](portainer-configs-k6.png)](portainer-configs-k6.png)
 
 {{< highlight host="stack" file="k6" >}}
@@ -371,6 +387,8 @@ data: {
 
 You can go even further with more progressive scenario. Create a new `k6_weather_test_02` docker config script :
 
+{{< highlight host="config" file="k6_weather_test_02" >}}
+
 ```js
 import http from "k6/http";
 import { check } from "k6";
@@ -386,6 +404,8 @@ export default function () {
 }
 ```
 
+{{< /highlight >}}
+
 This is a progressive 5 minutes load testing scenario from 1 user to 200 concurrent users.
 
 Then use this script on above `k6` stack and be sure to comment `K6_VUS` and `K6_DURATION` environment variables. Check the logs to ensure that you have correct scenario :