While I was working for a customer, I was tasked to create an Azure infrastructure, using Terraform and Azure DevOps (ADO). I thought about doing it like I usually do with GitLab but it wasn’t possible with ADO as it doesn’t store the state file itself. Instead I have to use an Azure Storage Account. I configured it, blocked public network, and realized that my pipeline couldn’t push the state in the Storage Account

In fact, ADO isn’t supported as a “Trusted Microsoft Service” and so it can’t bypass firewall rules using that option in Storage Accounts. For this to work, I had to create a self-hosted agent that run on Azure VM Scale Set and that will be the topic of this blog.

Azure resources creation

Agent Creation

First thing, we create a Azure VM Scale Set. I kept most parameters to their default values but it can be customized. I chose Linux as operating system as it was what I needed. One important thing is to set the “Orchestration mode” to “Uniform”, else ADO pipelines won’t work.

Storage account

For the storage account that will store our state, any storage account should work. Just note that you also need to create a container inside of it to fill your terraform provider. Also, for network preferences we will go with “Public access” and “Enable from selected networks”. This is will allow public access only from restricted networks. I do this to avoid creating a private endpoint to connect to a fully private storage account.

Entra ID identity for the pipeline

We also need to create an Entra ID Enterprise Application that we will provide to the pipeline. This identity must have Contributor (or any look alike) role over the scope you target. Also, it must have at least Storage Blob Data Contributor on the Storage Account to be able to write in it.

Azure DevOps setup

Terraform code

You can use any Terraform code you want, for my example I only use one which creates a Resource Group and a Virtual Network. Just note that your provider should look like this

Pipeline code

I’m used to split my pipeline in two files, the plan.yml will be given to the ADO pipeline and it will call the template to run its code. The things done in the pipeline are pretty simple. It installs Terraform on the VM Scale Set instance, then run the Terraform commands. The block of code can be reused for the “apply”.

Few things to note, in my plan.yml I set a Variable Group “Terraform_SPN” that I will show you just after. That’s where we will find the information about our previously created Entra Id Enterprise Application

In the template.yml, what is important to note is the pool definition. Here I point just a name, which correspond to ADO Agent Pool that I created. I’ll also show this step a bit further.

For the pipeline creation itself, we will go to Pipeline -> Create a new pipeline -> Azure Repos Git

Then Existing Azure Pipelines YAML file, and pick our file from our repo.

We will also create a Variable Group, the name doesn’t matter, just remember to put the same in your YAML code. Here you create 4 variables which are information coming from your tenant and your enterprise application. That’s gonna be used during the pipeline run to deploy your resources.

ADO Agent Pool

In the Project Settings, look for Agent Pools. Then create a new one and fill it as follow:

The Authorize button will appear after you select the subscription you want, and to accept this your user must have the Owner role, as it adds rights. This will allow ADO to communicate with Azure by creating a Service Principal. Then you can fill the rest as follow:

ADO pipeline run

When you first run your pipeline you must authorize it to use the Variable Group and the Agent pool.

One this is done, everything should go smoothly and end like this.

I hope that this blog was useful and could help you troubleshoot that king of problem between Azure and Azure DevOps.

L’article Deploying Azure Terraform code with Azure DevOps and a storage account as remote backend est apparu en premier sur dbi Blog.

Multi-stage build or not ?

Multi-stage builds are mainly useful when the projects require a build step to produce the final JavaScript files, such as with TypeScript. Generally, when the package.json contains a build scripts, it’s a good idea to use a multi-stage build.

The advantage is that the final image only contains the necessary files to run the application, which reduces the image size and improves security by excluding build tools and dependencies.

# -------- Build --------
FROM node:24-slim AS builder
WORKDIR /app

COPY . .
RUN npm ci

RUN npm run build

# -------- Runtime --------
FROM node:24-slim
WORKDIR /app

ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev

COPY --from=builder /app/dist .

USER node
EXPOSE 80
CMD ["node", "index.js"]

The main idea behind multi-stage build is to separate the containers for build and execution.

The build stage contains the source code and its own dependencies and tools, while the runtime stage only includes what is required to run the application. During the complete build process, we copy only the necessary files from the build stage to the runtime stage.

However, if your project is pure JavaScript without any build step, a single-stage build is sufficient and simpler.

Run the same packages in development and production

Your developers are the first users of your application. To avoid the ‘it works on my machine’ problem, it is important to ensure consistency between development and production environments.

That means using the same package versions in both environments.

To achieve this, use the command ‘npm ci’ instead of ‘npm install’ in your Dockerfile.

The ‘npm ci’ command installs the exact versions of the packages specified in the package-lock.json file, ensuring that both development and production environments use the same dependencies.

Note: add the option `–omit=dev` in runtime build to avoid installing dev dependencies.

Carefully choose the base image

The base image is the foundation of your Docker image. Choosing the right base image can have a significant impact on the size, security, and performance of your application.

First, choosing a Node.js official image is a good practice. The most important is to select the right variant of the image. Image *-alpine is a popular choice because of its small size, but you must understand the implications

Alpine images use musl as C library instead of glibc, commonly, it’s not a problem for pure JavaScript applications. However, if your application relies on native modules or certain npm packages that expect glibc, you may encounter compatibility issues.

Another alternative is to use slim images, which are based on Debian with glibc. They are larger than alpine images but provide better compatibility with native modules.

When to choose a slim instead of alpine?

When your application depends on native modules or npm packages that require glibc, it’s safer to use a slim image to avoid compatibility issues. With the popularity of alpine images, the ecosystem has improved its support for musl, but some exotic packages may still cause incompatibility issues (or may require to compile binaries from sources).

Be aware of this when you choose your base image.

Conclusion

Containerizing a Node.js application requires careful consideration of build strategies, dependency management, and base image selection. All these choices depend on your application requirements. Therefore, evaluating your needs and choosing the best approach for your specific use case is the key to containerizing your application effectively.

L’article How to properly containerize a Node.js application est apparu en premier sur dbi Blog.

I’ve been using Tailscale to connect my personal devices for a while. I have it installed almost everywhere: on my laptop, my phone, my Synology NAS, etc. It is very convenient as it helps me connect to any device, from anywhere. Tailscale adds a virtual interface to your device and manages its own IP address (you’ll understand why this is important in a minute)

Tailscale automatically assigns a unique IP address to each device in your Tailscale network (known as a tailnet). This IP address is known as a Tailscale IP address and comes from the shared address space defined in RFC6598, known as Carrier-Grade NAT (CGNAT).
(source: https://tailscale.com/kb/1015/100.x-addresses)

Today, I’m taking it to the next level: I’d like to install Tailscale alongside one of my application pod and access the web interface my pod exposes, directly from my Tailscale network (aka Tailnet).

The challenge:

I’ve installed Tailscale on the VM hosting my Kubernetes cluster (it’s a 1 node cluster, just for playing). Cool, I can access the VM from any other device. However, what about the web app my pod provides? How can I access it from my Tailnet?

As mentioned before, Tailscale has its own IP addressing, using 100.x.y.z addresses : your devices are assigned an IP from this address space.

Moreover, the network interface Tailscale creates (tailscale0) is not a standard interface and Kubernetes cannot simply expose services through that interface as for any other NodePort. To do so, you need to deploy Tailscale in your Kubernetes cluster.

Let’s do that.

The options:

Tailscale offers several options to connect your cluster to your tailnet:

• Proxy: Tailscale proxies traffic to one of your Kubernetes services. Your tailnet devices can communicate with the service but not with any other Kubernetes resources. Tailscale users can reach the service using the proxy’s name.
• Sidecar: Tailscale runs as a sidecar next to a specific pod in your cluster. It lets you expose that pod on your tailnet without allowing access to any others. Tailscale users can connect to the pod using its name.
• Subnet router: A subnet router deployment exposes your entire cluster network in your tailnet. Your Tailscale devices can connect to any pod or service in your cluster, provided that applicable Kubernetes network policies and Tailscale access controls allow it.

My use-case is to expose a specific pod to my tailnet (my speedtest-tracker app frontend), the “sidecar” option is then enough for my need.
Let’s see how to configure that together.

I invite you to read my other blog about speedtest-tracker. This is the app we are going to work with today.
I’ve been using speedtest-tracker for a while, but the app is only available from within my local network for now. Let’s see how to adapt my app’s deployment definition to add the Tailscale sidecar container.

What we need:

1. An application (that’s my speedtest-tracker app that already exists)
2. To generate an auth key that will be used by the Tailscale service deployed into the cluster
3. A secret with this auth key value in my cluster, for my pod to authenticate to my Tailscale account.
4. A service account, role and role binding to configure RBAC for my deployment ( my pod will use this service account and RBAC permissions to interact with the cluster)
5. Finally, I will add the sidecar container running Tailscale alongside my speedtest-tracker app container

Generate an auth key

First, let’s generate the auth key from my Tailscale account web interface.
This is done under Settings –> Keys –> Generate auth key…

Fill out the form, and make the key reusable. Then configure the device this key applies to as ephemeral (so is your pod).
Copy the key value somewhere as we are going to need it in a moment.

Create a secret

I create my secret, here is my tailscale-secret.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: tailscale-auth
stringData:
  TS_AUTHKEY: <my key value from previous step>

I apply the configuration to my speedtest namespace:

kubectl apply -f tailscale-secret.yaml -n speedtest

Service account, role and role binding

Next step is to configure RBAC for my Tailscale deployment. I need a service account, a role and role binding. Lucky me, Tailscale doc is well written, all I need is to follow their instructions.

I create a manifest called tailscale-rbac.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tailscale

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tailscale
rules:
  - apiGroups: [""]
    resourceNames: ["tailscale-auth"]
    resources: ["secrets"]
    verbs: ["get", "update", "patch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tailscale
subjects:
  - kind: ServiceAccount
    name: tailscale
roleRef:
  kind: Role
  name: tailscale
  apiGroup: rbac.authorization.k8s.io

I apply the configuration to my speedtest namespace:

kubectl apply -f tailscale-rbac.yaml -n speedtest

Add the sidecar container to my deployment

Last step is to adapt my existing deployment to add the tailscale sidecar container.

Under the spec section, we need to assign the serviceAccount created previously, to the pod:

serviceAccountName: tailscale

Then I create the sidecar container as per the tailscale documentation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: speedtest-tracker
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: speedtest-tracker
  template:
    metadata:
      labels:
        app: speedtest-tracker
    spec:
      serviceAccountName: tailscale  ## <-- Add the Service Account Name
      containers:
        ##### Tailscal sidecar container definition#######
        - name: tailscale-sidecar
          image: ghcr.io/tailscale/tailscale:latest
          env:
            - name: TS_KUBE_SECRET
              value: tailscale-auth
            - name: TS_AUTHKEY
              valueFrom:
                secretKeyRef:
                  name: tailscale-auth
                  key: TS_AUTHKEY
            - name: TS_USERSPACE
              value: "false"
          securityContext:
            capabilities:
              add:
               - NET_ADMIN
        ######################

        - name: speedtest-tracker
          image: lscr.io/linuxserver/speedtest-tracker:latest
          ports:
            - containerPort: 80
          env:
            - name: PUID
              value: "1000"
            - name: PGID
              value: "1000"
            - name: DB_CONNECTION
              value: pgsql
            - name: DB_HOST
              value: postgres
            - name: DB_PORT
              value: "5432"
            - name: DB_DATABASE
              value: speedtest_tracker
            - name: DB_USERNAME
              value: speedy
            - name: DB_PASSWORD
              value: password

          volumeMounts:
            - mountPath: /config
              name: speedtest-tracker
      volumes:
        - name: speedtest-tracker
          persistentVolumeClaim:
            claimName: speedtest-tracker

I apply the configuration to my speedtest namespace:

kubectl apply -f speedtest-tracker.yaml -n speedtest

Quick check, my speedtest-tracker pod is now running with 2 containers inside:

Rancher:~/syno/speedtest # kubectl get pods -n speedtest
NAME                                READY   STATUS    RESTARTS   AGE
postgres-7958dd877c-f4d2l           1/1     Running   0          22h
speedtest-tracker-8975967cd-s2fmc   2/2     Running   0          105m

And that’s it!

I can now access my app from both networks : my local network and my tailnet.

My pod is now seen as a device in my Tailscale network and can communicate with my other machines.

Conclusion

What we’ve done is to turn our Pod into a Tailscale node by injecting a WireGuard interface into the Pod’s shared network namespace, with the help of a tailscale sidecar container. This allows encrypted traffic to flow directly to the app container without Kubernetes Services or Ingress.

This is it, I hope you enjoyed reading this blog and that you learned something new.

If so, drop a like, it’s always appreciated 😉

To go further, please visit the Tailscale official documentation that will take you through all the steps and options to configure your tailnet on Kubernetes:
https://tailscale.com/learn/managing-access-to-kubernetes-with-tailscale#sidecar-deployments

L’article Access your Kubernetes pods via Tailscale using a Sidecar container est apparu en premier sur dbi Blog.

In this article, I will explain how I containerized my Vuetify + Vue 3 application with GitLab CI/CD.

My goal was to deploy my application on Kubernetes. To achieve this, I need to:

• Build the Vue 3 application
• Build the Docker image
• Push the image to the GitLab registry

Quick overview: overall, the full project uses a micro-service architecture and runs on Kubernetes. The Vue 3 project only contains the UI, and we containerize it and serve it with an Nginx image. The backend is a REST API built with NestJS, and we containerize it separately.

Add a Dockerfile to the project

First, I need a Dockerfile to build the image for my application. In this Dockerfile, I use a double-stage build. As a result, a final image containing only what is strictly necessary.

# Build the Vue.js application
FROM node:current-alpine AS build
COPY . ./app
WORKDIR /app
RUN npm install
RUN npm run build 

# Final Nginx container
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

The important part in this Dockerfile is the multi-stage build.
The first part, with the Node container, build the application, but production does not require all the tools used during this step.
As a result, the second step copies only the dist folder, the result of the build, and embeds it into an Nginx container to serve the generated files.

Add the CI/CD pipeline configuration

In the second step, I add the .gitlab-ci.yml file to the project root directory.

This file configures the pipeline, I use the docker-in-docker service to build the image. First, I login into the registry of my project. Next, I build and push the image.

stages:
- build

build:
  # Use the official docker image.
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    # Login to the gitlab registry
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    # Build and push the image
    - docker build --pull -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

  # Run this job where a Dockerfile exists
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - Dockerfile

Note: all the variables ($CI_REGISTRY_IMAGE, $CI_COMMIT_SHA…) used in the .gitlab-ci.yml are predefined variables provided by GitLab CI/CD.

Build the container

Once I push the .gitlab-ci.yml file, GitLab automatically triggers the pipeline following the rules definition.

After completion, the status of the pipeline is green and the status passed

As expected, the image is available in the registry of the project.

Conclusion

In summary, properly containerizing a Vue application is easy, but it requires to separate build and execution. A multi-step build with an Nginx container produces a lightweight, production-ready image.

L’article Containerize Vue 3 application with GitLab CI/CD est apparu en premier sur dbi Blog.

Creating a new organization is just a matter of a few clicks:

The only change to the default settings is the visibility, which is changed to private. The interface directly switches to the new organizations once it is created:

The next step is to create and initialize a new repository, which is also just a matter of a few clicks:

All the defaults, except for the “private” flag.

To clone this repository locally you’ll need to add your public ssh key to your user’s profile:

Once you have that, the repository can be cloned as usual:

dwe@ltdwe:~/Downloads$ git clone ssh://git@192.168.122.66/dwe/myrepo.git
Cloning into 'myrepo'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), done.
dwe@ltdwe:~/Downloads$ ls -la myrepo/
total 4
drwxr-xr-x 1 dwe dwe  26 Dec 15 09:41 .
drwxr-xr-x 1 dwe dwe 910 Dec 15 09:41 ..
drwxr-xr-x 1 dwe dwe 122 Dec 15 09:41 .git
-rw-r--r-- 1 dwe dwe  16 Dec 15 09:41 README.md

So far so good, lets create a new “Action”. Before we do that, we need to check that actions are enabled for the repository:

What we need now is a so-called “Runner”. A “Runner” is a daemon that fetches work from an Forgejo instance, executes and returns back the result. For the “Runner” we’ll use a Debian 13 minimal setup:

root@debian13:~$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.2
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

The only requirement is to have Git, curl and jq installed, so:

root@debian13:~$ apt install -y git curl jq
root@debian13:~$ git --version
git version 2.47.3

Downloading and installing the runner (this is a copy/paste from the official documentation):

root@debian13:~$ export ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
root@debian13:~$ echo $ARCH
amd64
root@debian13:~$ export RUNNER_VERSION=$(curl -X 'GET' https://data.forgejo.org/api/v1/repos/forgejo/runner/releases/latest | jq .name -r | cut -c 2-)
root@debian13:~$ echo $RUNNER_VERSION
12.1.2
root@debian13:~$ export FORGEJO_URL="https://code.forgejo.org/forgejo/runner/releases/download/v${RUNNER_VERSION}/forgejo-runner-${RUNNER_VERSION}-linux-${ARCH}"
root@debian13:~$ wget -O forgejo-runner ${FORGEJO_URL}
root@debian13:~$ chmod +x forgejo-runner
root@debian13:~$ wget -O forgejo-runner.asc ${FORGEJO_URL}.asc
root@debian13:~$ gpg --keyserver hkps://keys.openpgp.org --recv EB114F5E6C0DC2BCDD183550A4B61A2DC5923710
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key A4B61A2DC5923710: public key "Forgejo <contact@forgejo.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
root@debian13:~$ gpg --verify forgejo-runner.asc forgejo-runner && echo "✓ Verified" || echo "✗ Failed"
gpg: Signature made Sat 06 Dec 2025 11:10:50 PM CET
gpg:                using EDDSA key 0F527CF93A3D0D0925D3C55ED0A820050E1609E5
gpg: Good signature from "Forgejo <contact@forgejo.org>" [unknown]
gpg:                 aka "Forgejo Releases <release@forgejo.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EB11 4F5E 6C0D C2BC DD18  3550 A4B6 1A2D C592 3710
     Subkey fingerprint: 0F52 7CF9 3A3D 0D09 25D3  C55E D0A8 2005 0E16 09E5
✓ Verified

Move that to a location which is in the PATH:

root@debian13:~$ mv forgejo-runner /usr/local/bin/forgejo-runner
root@debian13:~$ forgejo-runner -v
forgejo-runner version v12.1.2

As usual, a separate user should be created to run a service:

root@debian13:~$ groupadd runner
root@debian13:~$ useradd -g runner -m -s /bin/bash runner

As the runner will use Docker, Podman or LXC to execute the Actions, we’ll need to install Podman as well:

root@debian13:~$ apt install -y podman podman-docker
root@debian13:~$ podman --version
podman version 5.4.2
root@debian13:~$ systemctl enable --now podman.socket
root@debian13:~$ machinectl shell runner@
Connected to the local host. Press ^] three times within 1s to exit session.
runner@debian13:~$ systemctl --user enable --now podman.socket
Created symlink '/home/runner/.config/systemd/user/sockets.target.wants/podman.socket' → '/usr/lib/systemd/user/podman.socket'.

Now we need to register the runner with the Forgejo instance. Before we can do that, we need to fetch the registration token:

Back on the runner, register it:

root@debian13:~$ su - runner
runner@debian13:~$ forgejo-runner register
INFO Registering runner, arch=amd64, os=linux, version=v12.1.2. 
WARN Runner in user-mode.                         
INFO Enter the Forgejo instance URL (for example, https://next.forgejo.org/): 
http://192.168.122.66:3000/
INFO Enter the runner token:                      
BBE3MbNuTl0Wl52bayiRltJS8ciagRqghe7bXIXE
INFO Enter the runner name (if set empty, use hostname: debian13): 
runner1
INFO Enter the runner labels, leave blank to use the default labels (comma-separated, for example, ubuntu-20.04:docker://node:20-bookworm,ubuntu-18.04:docker://node:20-bookworm): 

INFO Registering runner, name=runner1, instance=http://192.168.122.66:3000/, labels=[docker:docker://data.forgejo.org/oci/node:20-bullseye]. 
DEBU Successfully pinged the Forgejo instance server 
INFO Runner registered successfully.              
runner@debian13:~$ 

This will make the new runner visible in the interface, but it is in “offline” state:

Time to startup the runner:

root@debian13:~$ cat /etc/systemd/system/forgejo-runner.service
[Unit]
Description=Forgejo Runner
Documentation=https://forgejo.org/docs/latest/admin/actions/
After=docker.service

[Service]
ExecStart=/usr/local/bin/forgejo-runner daemon
ExecReload=/bin/kill -s HUP $MAINPID

# This user and working directory must already exist
User=runner 
WorkingDirectory=/home/runner
Restart=on-failure
TimeoutSec=0
RestartSec=10

[Install]
WantedBy=multi-user.target

root@debian13:~$ systemctl daemon-reload
root@debian13:~$ systemctl enable forgejo-runner
root@debian13:~$ systemctl start forgejo-runner

Once the runner is running, the status in the interface will switch to “Idle”:

Ready for our first “Action”. Actions are defined as a yaml file in a specific directory of the repository:

dwe@ltdwe:~/Downloads/myrepo$ mkdir -p .forgejo/workflows/
dwe@ltdwe:~/Downloads/myrepo$ cat .forgejo/workflows/demo.yaml
on: [push]
jobs:
  test:
    runs-on: docker
    steps:
      - run: echo All good!

dwe@ltdwe:~/Downloads/myrepo$ git add .forgejo/
dwe@ltdwe:~/Downloads/myrepo$ git commit -m "my first action"
[main f9aa487] my first action
 1 file changed, 6 insertions(+)
 create mode 100644 .forgejo/workflows/demo.yaml
dwe@ltdwe:~/Downloads/myrepo$ git push

What that does: Whenever there is a “push” to the repository, a job will be executed on the runner with label “docker” which doesn’t do more than printing “All good!”. If everything went fine you should see the result under “Actions” section of the repository:

Nice, now we’re ready to do some real work, bust this is the topic for the next post.

L’article Forgejo: Organizations, Repositories and Actions est apparu en premier sur dbi Blog.

As FreeBSD 15 was released on 2. December that’s the perfect chance to get that up and running there and have a look how it feels like. I am not going into the installation of FreeBSD 15, this really is straight forward. I just want to mention that I opted for the “packaged base system” instead of the distributions sets which is currently in tech preview. What that means is that the whole system is installed and managed with packages and you don’t need freebsd-update anymore. Although it is still available, it will not work anymore if you try to use it:

root@forgejo:~ $ cat /etc/os-release 
NAME=FreeBSD
VERSION="15.0-RELEASE"
VERSION_ID="15.0"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 15.0-RELEASE"
CPE_NAME="cpe:/o:freebsd:freebsd:15.0"
HOME_URL="https://FreeBSD.org/"
BUG_REPORT_URL="https://bugs.FreeBSD.org/"
root@forgejo:~ $ freebsd-update fetch
freebsd-update is incompatible with the use of packaged base.  Please see
https://wiki.freebsd.org/PkgBase for more information.

Coming back to Forgejo: On FreeBSD this is available as a package, so you can just go ahead and install it:

root@forgejo:~$ pkg search forgejo
forgejo-13.0.2_1               Compact self-hosted Git forge
forgejo-act_runner-9.1.0_2     Act runner is a runner for Forgejo based on the Gitea Act runner
forgejo-lts-11.0.7_1           Compact self-hosted Git forge
forgejo7-7.0.14_3              Compact self-hosted Git service
root@forgejo:~ $ pkg install forgejo
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
The following 32 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        FreeBSD-clibs-lib32: 15.0 [FreeBSD-base]
        brotli: 1.1.0,1 [FreeBSD-ports]
...
Number of packages to be installed: 32

The process will require 472 MiB more space.
100 MiB to be downloaded.

Proceed with this action? [y/N]: y
Message from python311-3.11.13_1:

--
Note that some standard Python modules are provided as separate ports
as they require additional dependencies. They are available as:

py311-gdbm       databases/py-gdbm@py311
py311-sqlite3    databases/py-sqlite3@py311
py311-tkinter    x11-toolkits/py-tkinter@py311
=====
Message from git-2.51.0:

--
If you installed the GITWEB option please follow these instructions:

In the directory /usr/local/share/examples/git/gitweb you can find all files to
make gitweb work as a public repository on the web.

All you have to do to make gitweb work is:
1) Please be sure you're able to execute CGI scripts in
   /usr/local/share/examples/git/gitweb.
2) Set the GITWEB_CONFIG variable in your webserver's config to
   /usr/local/etc/git/gitweb.conf. This variable is passed to gitweb.cgi.
3) Restart server.


If you installed the CONTRIB option please note that the scripts are
installed in /usr/local/share/git-core/contrib. Some of them require
other ports to be installed (perl, python, etc), which you may need to
install manually.
=====
Message from git-lfs-3.6.1_8:

--
To get started with Git LFS, the following commands can be used:

  1. Setup Git LFS on your system. You only have to do this once per
     repository per machine:

     $ git lfs install

  2. Choose the type of files you want to track, for examples all ISO
     images, with git lfs track:

     $ git lfs track "*.iso"

  3. The above stores this information in gitattributes(5) files, so
     that file needs to be added to the repository:

     $ git add .gitattributes

  4. Commit, push and work with the files normally:

     $ git add file.iso
     $ git commit -m "Add disk image"
     $ git push
=====
Message from forgejo-13.0.2_1:

--
Before starting forgejo for the first time, you must set a number of
secrets in the configuration file. For your convenience, a sample file
has been copied to /usr/local/etc/forgejo/conf/app.ini.

You need to replace every occurence of CHANGE_ME in the file with
sensible values. Please refer to the official documentation at
https://forgejo.org for details.

You will also likely need to create directories for persistent storage.
Run
    su -m git -c 'forgejo doctor check'
to check if all prerequisites have been met.

What I really like with the FreeBSD packages is, that they usually give clear instructions on what to do. We’ll go with the web-based installer, so:

root@forgejo:~ $ chown git:git /usr/local/etc/forgejo/conf
root@forgejo:~ $ rm /usr/local/etc/forgejo/conf/app.ini
root@forgejo:~ $ service -l | grep for
forgejo
root@forgejo:~ $ service forgejo enable
forgejo enabled in /etc/rc.conf
root@forgejo:~ $ service forgejo start
2025/12/12 14:16:42 ...etting/repository.go:318:loadRepositoryFrom() [W] SCRIPT_TYPE "bash" is not on the current PATH. Are you sure that this is the correct SCRIPT_TYPE?

[1] Check paths and basic configuration
 - [E] Failed to find configuration file at '/usr/local/etc/forgejo/conf/app.ini'.
 - [E] If you've never ran Forgejo yet, this is normal and '/usr/local/etc/forgejo/conf/app.ini' will be created for you on first run.
 - [E] Otherwise check that you are running this command from the correct path and/or provide a `--config` parameter.
 - [E] Cannot proceed without a configuration file
FAIL
Command error: stat /usr/local/etc/forgejo/conf/app.ini: no such file or directory

2025/12/12 14:16:42 ...etting/repository.go:318:loadRepositoryFrom() [W] SCRIPT_TYPE "bash" is not on the current PATH. Are you sure that this is the correct SCRIPT_TYPE?

[1] Check paths and basic configuration
 - [E] Failed to find configuration file at '/usr/local/etc/forgejo/conf/app.ini'.
 - [E] If you've never ran Forgejo yet, this is normal and '/usr/local/etc/forgejo/conf/app.ini' will be created for you on first run.
 - [E] Otherwise check that you are running this command from the correct path and/or provide a `--config` parameter.
 - [E] Cannot proceed without a configuration file
FAIL
Command error: stat /usr/local/etc/forgejo/conf/app.ini: no such file or directory

Seems bash is somehow expected, but this is not available right now:

root@forgejo:~ $ which bash
root@forgejo:~ $ 

Once more:

root@forgejo:~ $ pkg install bash
root@forgejo:~ $ service forgejo stop
Stopping forgejo.
root@forgejo:~ $ service forgejo start

[1] Check paths and basic configuration
 - [E] Failed to find configuration file at '/usr/local/etc/forgejo/conf/app.ini'.
 - [E] If you've never ran Forgejo yet, this is normal and '/usr/local/etc/forgejo/conf/app.ini' will be created for you on first run.
 - [E] Otherwise check that you are running this command from the correct path and/or provide a `--config` parameter.
 - [E] Cannot proceed without a configuration file
FAIL
Command error: stat /usr/local/etc/forgejo/conf/app.ini: no such file or directory
root@forgejo:~ $ service forgejo status
forgejo is running as pid 3448.

The web installer is available on port 3000 and you can choose between the usual database backends:

To keep it simple I went with SQLite3, kept everything at the default and provided the Administrator information further down the screen. Before the installer succeeded I had to create these two directories:

root@forgejo:~ $ mkdir /usr/local/share/forgejo/data/
root@forgejo:~ $ chown git:git /usr/local/share/forgejo/data/
root@forgejo:~ $ mkdir /usr/local/share/forgejo/log
root@forgejo:~ $ chown git:git /usr/local/share/forgejo/log

Once that was done it went fine and this is the welcome screen:

As with the other tools in that area there are the common sections like “Issues”, “Pull requests”, and “Milestones”.

In the next post we’re going to create an organization, a repository and try to create a simple, how GitLab calls it, pipeline.

L’article What is Forgejo and getting it up and running on FreeBSD 15 est apparu en premier sur dbi Blog.

It turns out that there is a project called Speedtest-tracker, written and maintained by Alex Justesen on GitHub that does just what I was looking for. Behind the scenes, speedtest-tracker uses the official Ookla CLI.

Speedtest Tracker is a self-hosted application that monitors the performance and uptime of your internet connection. Built using Laravel and Speedtest CLI from Ookla®, deployable with Docker.

The cool thing is that Speedtest Tracker is containerized; you can run it anywhere you want! At first, I had installed it as a Docker container on my Synology, but the NAS I own only has 1Gbps Ethernet ports, and my ISP advertises DL/UL speeds of 5 Gbps / 900 Mbps

I have a mini PC that I use for my YaK projects, which embeds a 2.5Gbps Ethernet card. I’d rather use this machine than the NAS. Even though I will not be able to test the full speed my ISP provides, at least I will be able to see if I get near 2.5Gbps, which is already a great download speed.

OK, enough talking, let’s get our hands dirty and let’s deploy Speedtest-tracker!

Your list of ingredients

Here is what you need to add to your recipe:

• A hypervisor, in my case I’m using Proxmox
• A virtual machine (on which I’m using SUSE Linux, but any distro will work just fine)
• A Kubernetes cluster. Keep it simple, install a single node RKE2
• A persistent volume: local-path provisioner does the job

I’m passing these steps here, but you can find them in my other blog dedicated to installing the YaK, if you need.

Everything is well documented on Speedtest tracker web page

There is already a community manifest available for Kubernetes, written and maintained by Maxime Moreillon.

How to install speedtest-tracker?

Installing speedtest tracker is as simple as deploying 2 yaml files:

• 1 for the postgreSQL database
• 1 for the frontend app

The PG database and the application manifests are available here.
All the credit goes to Maxime Moreillon, who wrote these manifests and made them available to the community.
All I had to do was save the files to my “speedtest” folder and adjust them to my context.

localhost:~ # cd speedtest
localhost:~/speedtest # ls -ltrh
total 8.0K
-rw-r--r-- 1 root root 1.1K Jul 29 16:29 postgres.yaml
-rw-r--r-- 1 root root 2.2K Aug  3 18:48 speedtest-tracker.yaml

My Postgres manifest

I haven’t changed a single line from Maxime Moreillon’s code. The manifest includes the PVC definition, the PostgreSQL deployment itself, and a service:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:15.1
          env:
            - name: POSTGRES_PASSWORD
              value: password
            - name: POSTGRES_DB
              value: speedtest_tracker
            - name: POSTGRES_USER
              value: speedy
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: postgres
      volumes:
        - name: postgres
          persistentVolumeClaim:
            claimName: postgres

---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  ports:
    - port: 5432
  selector:
    app: postgres
  type: ClusterIP

My speedtest-tracker manifest

With a few adjustments from Maxime’s code to fit my needs. It comes with the PVC definition, the application deployment, and the service:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: speedtest-tracker
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-path  # Adjust if you're using a different StorageClass

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: speedtest-tracker
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: speedtest-tracker
  template:
    metadata:
      labels:
        app: speedtest-tracker
    spec:
      containers:
        - name: speedtest-tracker
          image: lscr.io/linuxserver/speedtest-tracker:latest
          ports:
            - containerPort: 80
          env:
            - name: PUID
              value: "1000"
            - name: PGID
              value: "1000"
            - name: DB_CONNECTION
              value: pgsql
            - name: DB_HOST
              value: postgres
            - name: DB_PORT
              value: "5432"
            - name: DB_DATABASE
              value: speedtest_tracker
            - name: DB_USERNAME
              value: speedy
            - name: DB_PASSWORD
              value: password

########MY PERSONAL ENV VARIABLES########
            - name: APP_NAME
              value: home-speedtest-k8s
            - name: APP_KEY
              value: <generate your own app key>
            - name: DISPLAY_TIMEZONE
              value: Europe/Paris
            - name: SPEEDTEST_SERVERS
              value: "62493"
            - name: SPEEDTEST_SCHEDULE
              value: '*/30 * * * *'
            - name: PUBLIC_DASHBOARD
              value: "true"
#########################################

          volumeMounts:
            - mountPath: /config
              name: speedtest-tracker
      volumes:
        - name: speedtest-tracker
          persistentVolumeClaim:
            claimName: speedtest-tracker

---
apiVersion: v1
kind: Service
metadata:
  name: speedtest-tracker
  labels:
    app: speedtest-tracker
spec:
  selector:
    app: speedtest-tracker
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30080  # You can change this to any port in the 30000-32767 range

Now, generate your own APP KEY and paste the value in the placeholder in the code above (including the base64: prefix), here is how:

echo -n 'base64:'; openssl rand -base64 32;

And that’s it!
Once your manifests are ready and once you are happy with the environment variables you want (the list of env. variables is available here), you just need to create your namespace on your cluster and apply the configuration:

kubectl create ns speedtest
kubectl apply -f speedtest/postgres.yaml -n speedtest
kubectl apply -f speedtest/speedtest-racker.yaml -n speedtest

After a few seconds, your pods will come up:

localhost:~/speedtest # kubectl get pods -n speedtest
NAME                                 READY   STATUS    RESTARTS        AGE
postgres-6c8499b968-rbwlw            1/1     Running   2 (4d18h ago)   5d21h
speedtest-tracker-7997cbdc8f-64n7c   1/1     Running   0               19h

Enjoy !

If you did things right, you should be able to monitor your internet speed and display the results on a neat UI. In my case, I fire a speedtest every 30 minutes (I know, that’s overkill, but I just wanted to play a bit. I will reduce the frequency to something more reasonable, I promise )

Cool, no?

To go further

I’d love to monitor the full bandwidth my ISP advertises, but I’m limited by my hardware: my router does not support link aggregation, and it only comes with one 10G fiber-optic WAN interface + one 2.5 Gbps and two 1Gbps LAN interfaces. There is no chance I can test the full fiber-optic capacity with this hardware.

In the future, I might buy a switch that supports LACP and configure my router in bridge mode to be able to reach the full WAN bandwidth, or invest in a router that provides more high-speed interfaces. But to be honest, the investment is not really worth it.

One thing I could do however would be to enable HTTPS and add a Let’s Encrypt certificate to secure the connections to my frontend. That’s an improvement I could make soon.

L’article Monitor your ISP’s performance with Speedtest Tracker est apparu en premier sur dbi Blog.

You can run a playbook for specific host(s), a group of hosts, or “all” (all hosts of the inventory).

Ansible will then run the tasks in parallel on the specified hosts. To avoid an overload, the parallelism – called “forks” – is limited to 5 per default.

A task with a loop (e.g. with_items:) will be executed serially per default. To run it in parallel, you can use the “async” mode.

But unfortunately, this async mode will not work to include roles or other playbooks in the loop. In this blog post we will see a workaround to run roles in parallel (on the same host).

Parallelization over the ansible hosts

In this example, we have 3 hosts (dbhost1, dbhost2, dbhost3) in the dbservers group
(use ansible-inventory --graph to see all your groups) and we run the following sleep1.yml playbook

- name: PLAY1
  hosts: [dbservers]
  gather_facts: no
  tasks:
    - ansible.builtin.wait_for: timeout=10

The tasks of the playbook will run in parallel on all hosts of the dbservers group, but not more at the same time as specified with the “forks” parameter. (specified in ansible.cfg, shell-variable ANSIBLE_FORKS, commandline parameter –forks)
https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_strategies.html

$ time ansible-playbook sleep1.yml --forks 2
...
ok: [dbhost1]  #appears after 10sec
ok: [dbhost2]  #appears after 10sec
ok: [dbhost3]  #appears after 20sec
...
real    0m22.384s

With forks=2 the results of dbhost1 and dbhost2 will both be returned after 10 seconds (sleep 10 in parallel). dbhost3 has to wait until one of the running tasks is completed. So the playbook will complete after approx. 20 seconds. If forks is 1, then it takes 30s, if forks is 3, it takes 10s (plus overhead).

Parallelization of loops

Per default, a loop is not run in parallel

- name: PLAY2A
  hosts: localhost
  tasks:
    - set_fact:
        sleepsec: [ 1, 2, 3, 4, 5, 6, 7 ]

    - name: nonparallel loop
      ansible.builtin.wait_for: "timeout={{item}} "
      with_items: "{{sleepsec}}"
      register: loop_result

This sequential run will take at least 28 seconds.

To run the same loop in parallel, use “async”
https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_async.html

- name: PLAY2B
  hosts: localhost
  gather_facts: no
  tasks:
    - name: parallel loop
      ansible.builtin.wait_for: "timeout={{item}}"
      with_items: "{{sleepsec}}"
      register: loop_result
      async: 600  # Maximum runtime in seconds. Adjust as needed.
      poll: 0     # Fire and continue (never poll here)

    # in the meantime, you can run other tasks

    - name: Wait for parallel loop to finish (poll)
      async_status:
        jid: "{{ item.ansible_job_id }}"
      register: loop_check
      until: loop_check.finished
      delay: 1      # Check every 1 seconds
      retries: 600  # Retry up to 600 times. 
                    # delay*retries should be "async:" above
      with_items: "{{ loop_result.results }}"

In the first task we start all sleeps in parallel. It will timeout after 600 seconds. We will not wait for the result (poll: 0). A later task polls the background processes until all parallel loops are finished. This execution only takes a little bit more than 7 seconds (the longest sleep plus some overhead). Between the loop and the poll you can add other tasks to use the waiting time for something more productive. Or if you know your loop takes at least 1 minute, then you can add to reduce the overhead of the polling loop, an ansible.builtin.wait_for: "timeout=60".

For example, we have an existing role to create and configure a new useraccount with many, sometimes longer running steps, e.g. add to LDAP, create NFS share, create a certificate, send a welcome-mail, ….; most of these tasks are not bound to a specific host, and will run on “localhost” calling a REST-API.

The following code example is a dummy role for copy/paste to see how it works with parallel execution.

# roles/create_user/tasks/main.yml    
    - debug: var=user
    - ansible.builtin.wait_for: timeout=10

Now we have to create many useraccounts and would like to do that in parallel. We use the code above and adapt it:

- name: PLAY3A
  hosts: localhost
  gather_facts: no
  tasks:
    - set_fact:
        users: [ 'Dave', 'Eva', 'Hans' ]

    - name: parallel user creation
      ansible.builtin.include_role: name=create_user
      with_items: "{{users}}"
      loop_control:
        loop_var: user
      register: loop_result
      async: 600
      poll: 0

But unfortunately, Ansible will not accept include_role:
ERROR! 'poll' is not a valid attribute for a IncludeRole

The only solution is to rewrite the role and to run every task with the async mode.

But is there no better solution to re-use existing roles? Let’s see…

Parallel execution of roles in a loop

As we already know

• Ansible can run playbooks/tasks in parallel over different hosts (hosts parameter of the play).
• Ansible can run tasks with a loop in parallel with the async option, but
• Ansible can NOT run tasks with a loop in parallel for include_role or include_tasks

So, the trick will be to run the roles on “different” hosts. There is a special behavior of localhost. Well-known is the localhost IP 127.0.0.1; But also 127.0.0.2 to 127.255.255.254 refer to localhost (check it with ‘ping’). For our create-user script: we will run it on “different” localhosts in parallel. For that, we create a host-group at runtime with localhost addresses. The number of these localhost IP’s is equal to the number of users to create.

users[0] is Dave. It will be created on 127.0.0.1
users[1] is Eva. It will be created on 127.0.0.2
users[2] is Hans. It will be created on 127.0.0.3
…

- name: create dynamic localhosts group
  hosts: localhost
  gather_facts: no
  vars:
    users: [ 'Dave', 'Eva', 'Hans' ]
  tasks:
    # Create a group of localhost IP's; 
    # Ansible will treat it as "different" hosts.
    # To know, which locahost-IP should create which user:
    # The last 2 numbers of the IP matches the element of the {{users}} list:
    # 127.0.1.12 -> (1*256 + 12)-1 = 267 -> users[267]
    # -1: first Array-Element is 0, but localhost-IP starts at 127.0.0.1
    - name: create parallel execution localhosts group
      add_host:
        name: "127.0.{{item|int // 256}}.{{ item|int % 256 }}"
        group: localhosts
      with_sequence:  start=1  end="{{users|length}}" 

- name: create useraccounts
  hosts: [localhosts]  # [ 127.0.0.1, 127.0.0.2, ... ]
  connection: local
  gather_facts: no
  vars:
    users: [ 'Dave', 'Eva', 'Hans' ]
  # this play runs in parallel over the [localhosts] 
  tasks:
    - set_fact:
        ip_nr: "{{ inventory_hostname.split('.') }}"

    - name: parallel user creation
      ansible.builtin.include_role:
        name: create_user
      vars:
        user: "{{ users[ (ip_nr[2]|int*256 + ip_nr[3]|int-1) ] }}"

In this example: With forks=3 it runs in 11 seconds. With forks=1 (no parallelism) it takes 32 seconds.

The degree of parallelism (forks) depends on your use-case and your infrastructure. If you have to restore files, probably the network-bandwith, disk-I/O or the number of tape-slots is limited. Choose a value of forks that does not overload your infrastructure.

If some tasks or the whole role has to be run on another host than localhost (e.g. create a local useraccount on a server), then you can use delegate_to: "{{remote_host}}".

This principle can ideally be used for plays that are not bound to a specific host, usually for tasks that will run from localhost and calling a REST-API without logging in with ssh to a server.

Summary

Ansible is optimized to run playbooks on different hosts in parallel. The degree of parallelism can be limited by the “forks” parameter (default 5).

Ansible can run loops in parallel with the async mode. Unfortunately that does not work if we include a role or tasks.

The workaround to run roles in parallel on the same host is to assign every loop item to a different host, and then to run the role on different hosts. For the different hosts we can use the localhost IP’s between 127.0.0.1 and 127.255.255.254 to build a dynamic host-group; the number corresponds to number of loop items

L’article Parallel execution of Ansible roles est apparu en premier sur dbi Blog.

Morning Kick-Off: Sponsors and Opening

The day started with a short introduction and a presentation of the sponsors. A good opportunity to acknowledge the partners who made this event possible.

Session 1: Composable AI and Its Impact on Enterprise Architecture

This session (by Felix Mutzl) provided a strategic view of how AI is becoming a core part of enterprise architecture.

Session 2: Migrate Your On-Premises SQL Server Databases to Microsoft Azure

A session (by Edwin M Sarmiento) that addressed one of the most common challenges for many DBAs and IT departments: how to migrate your SQL Server workloads to Azure. The speaker shared a well-structured approach, highlighting the key elements to consider before launching a migration project:

• Team involvement: Ensure all stakeholders are aligned.
• Planning: Migration isn’t just about moving data, dependencies must be mapped.
• Cost: Evaluate Azure pricing models and estimate consumption.
• Testing: Validate each stage in a non-production environment.
• Monitoring: Post-migration monitoring is essential for stability.

Session 3: Fabric Monitoring Made Simple: Built-In Tools and Custom Solutions

This session was produced by Just Blindbaek and he talked about how Microsoft Fabric is gaining traction quickly, and with it comes the need for robust monitoring. This session explored native tools like Monitoring Hub, Admin Monitoring workspace, and Workspace Monitoring. In addition, the speaker introduced FUAM (Fabric Unified Admin Monitoring), an open-source solution supported by Microsoft that complements the built-in options.

Session 4: Database DevOps…CJ/CD: Continuous Journey or Continuous Disaster?

A hands-on session (by Tonie Huizer) about introducing DevOps practices in a legacy team that originally used SVN and had no automation. The speaker shared lessons learned from introducing:

• Sprint-based development cycles
• Git branching strategies
• Build and release pipelines
• Manual vs Pull Request releases
• Versioned databases and IDPs

It was a realistic look at the challenges and practical steps involved when modernizing a database development process.

Session 5: (Developer) Productivity, Data Intelligence, and Building an AI Application

This session (from Felix Mutzl) shifted the focus from general AI to productivity-enhancing solutions. Built on Databricks, the use case demonstrated how to combine AI models with structured data to deliver real-time insights to knowledge workers. The practical Databricks examples were especially helpful to visualize the architecture behind these kinds of applications.

Session 6: Azure SQL Managed Instance Demo Party

The final session of the day was given by Dani Ljepava and Sasa Popovic and was more interactive and focused on showcasing the latest Azure SQL Managed Instance features. Demos covered:

• Performance and scaling improvements
• Compatibility for hybrid scenarios
• Built-in support for high availability and disaster recovery

The session served as a great update on where Azure SQL MI is heading and what tools are now available for operational DBAs and cloud architects.

Thank you, Amine Haloui.

L’article SQLDay 2025 – Wrocław – Sessions est apparu en premier sur dbi Blog.

In this first post, I’ll focus on Monday’s workshops.

Day 1 – Workshop Sessions

The workshop day at SQLDay is always a strong start. It gives attendees the opportunity to focus on a specific topic for a full day. This year, several tracks were available in parallel, covering various aspects of the Microsoft data stack: from Power BI and SQL Server to Azure and Microsoft Fabric.

Here are the sessions that were available:

Advanced DAX

This session was clearly targeted at experienced Power BI users. Alberto Ferrari delivered an in-depth look into evaluation context, expanded tables, and advanced usage of CALCULATE. One focus area was the correct use of ALLEXCEPT and how it interacts with complex relationships.

Execution Plans in Depth

For SQL Server professionals interested in performance tuning, this workshop provided a detailed walkthrough of execution plans. Hugo Kornelis covered a large number of operators, explained how they work internally, and showed how to analyze problematic queries. The content was dense but well-structured.

Becoming an Azure SQL DBA

This workshop was led by members of the Azure SQL product team. It focused on the evolution of the DBA role in cloud environments. The agenda included topics such as high availability in Azure SQL, backup and restore, cost optimization, and integration with Microsoft Fabric. It was designed to understand the shared responsibility model and how traditional DBA tasks are shifting in cloud scenarios.

Enterprise Databots

This workshop explored how to build intelligent DataBots using Azure and Databricks. The session combined theoretical content with practical labs. The goal was to implement chatbots capable of interacting with SQL data and leveraging AI models. Participants had the opportunity to create bots from scratch.

Analytics Engineering with dbt

This session was focused on dbt (data build tool) and its role in ELT pipelines. It was well-suited for data analysts and engineers looking to standardize and scale their workflows.

Build a Real-time Intelligence Solution in One Day

This workshop showed how to implement real-time analytics solutions using Microsoft Fabric. It covered Real-Time Hub, Eventstream, Data Activator, and Copilot.

From Power BI Developer to Fabric Engineer

This workshop addressed Power BI developers looking to go beyond the limitations of Power Query and Premium refresh schedules. The session focused on transforming reports into scalable Fabric-based solutions using Lakehouse, Notebooks, Dataflows, and semantic models. A good starting point for anyone looking to shift from report building to full data engineering within the Microsoft ecosystem.

Thank you, Amine Haloui.

L’article SQLDay 2025 – Wrocław – Workshops est apparu en premier sur dbi Blog.