In the previous article, we’ve built an image using the image builder. So let’s create a new branch and a new version of the image builder.
$ cd image-builder
$ git checkout -b test
$ cd images/apiserver-network-proxy-agent/
$ v0.36.0-k0s.1 test
Let’s clone the Kubernetes-sigs repo and create a tgz archive for the next step
$ git clone https://github.com/kubernetes-sigs/apiserver-network-proxy.git k8ssigs-apiserver-network-proxy
$ cd k8ssigs-apiserver-network-proxy
$ tar cfz ../image-builder/images/apiserver-network-proxy-agent/test/k8ssigs-apiserver-network-proxy.tgz .
First, replace the wget from Github to use locally generated archive instead.
WORKDIR /go/src/kubernetes-sigs/apiserver-network-proxy
ARG VERSION HASH
RUN --mount=type=cache,id=konnectivity-go-modcache,target=/go/pkg/mod \
--mount=type=tmpfs,target=/tmp \
set -e \
&& wget -qO /tmp/src.tar.gz https://github.com/kubernetes-sigs/apiserver-network-proxy/archive/refs/tags/v$VERSION.tar.gz \
&& { echo $HASH /tmp/src.tar.gz | sha256sum -c -; } || { sha256sum /tmp/src.tar.gz; exit 1; } \
&& tar xf /tmp/src.tar.gz --strip-components=1
Add the COPY step and use local file instead of wget
COPY k8ssigs-apiserver-network-proxy.tgz /root
WORKDIR /go/src/kubernetes-sigs/apiserver-network-proxy
RUN --mount=type=cache,id=konnectivity-go-modcache,target=/go/pkg/mod \
--mount=type=tmpfs,target=/tmp \
set -e \
&& tar xfz /root/k8ssigs-apiserver-network-proxy.tgz && \
rm -vf /root/k8ssigs-apiserver-network-proxy.tgz
Lately, I’ve encounter some issues with my K0S Kubernetes distro running on my Raspberry Pi cluster. The Konnectivity agent is generating a lot of logs and error. This problem has already been reported (like here) but it has been closed without any real response. So let start digging this.
In this article, we will discuss about the build environment and dependencies. Namely, a container registry to store the artifacts to be tested, a multi architecture builder as the test environment runs on Raspberry Pi and the build environment is AMD64. Finally, validate all this by building and deploying an image using the code without any change.
Running a registry is simple as running a single container, using the registry image
Run an additional container for the user interface, using registry-ui for easier management.
Adds some environment so the web interface can query the registry without being rejected and you get the following services for Docker Compose.
services:
registry:
image: docker.io/library/registry:3.1.2
ports:
- 5000:5000
hostname: registry
restart: always
userns_mode: host
environment:
REGISTRY_HTTP_HEADERS_Access-Control-Allow-Origin: '[http://myserver.home.local:5080]'
REGISTRY_HTTP_HEADERS_Access-Control-Allow-Methods: '[HEAD,GET,OPTIONS,DELETE]'
REGISTRY_HTTP_HEADERS_Access-Control-Allow-Credentials: '[true]'
REGISTRY_HTTP_HEADERS_Access-Control-Allow-Headers: '[Authorization,Accept,Cache-Control]'
REGISTRY_HTTP_HEADERS_Access-Control-Expose-Headers: '[Docker-Content-Digest]'
REGISTRY_STORAGE_DELETE_ENABLED: 'true'
volumes:
- /srv/registry:/var/lib/registry
registry-ui:
image: joxit/docker-registry-ui:2.6.0
container_name: docker-registry-ui
ports:
- 5080:80
environment:
- REGISTRY_TITLE=myserver.home.local
- REGISTRY_URL=http://myserver.home.local:5000
- SINGLE_REGISTRY=true
- SHOW_CATALOG_NB_TAGS=true
depends_on:
- registry
restart: always
To use the local unsecure registry you must create a custom Docker Buildx builder. Here are the steps.
Create the first dashboard to access Victoria Logs in Grafana
First you need to add the victoriametrics-logs-datasource plugin. Then you can add the datasource.
Set the URL, then click on the Save & Test buttom at the bottom of the page.
Victoria Logs is a scalable logging solution designed to be fast and highly efficient. It provides users and organizations with better observability of their systems and helpsthem identify issues as well as debug, understand and analyze product behaviour.
The setup to runs Victoria Logs on Docker Compose is very easy. One port, one data volume and all the configuration is done through command line parameters. For this simple example, only one parameter: the storage data path.
services:
vic-logs:
image: docker.io/victoriametrics/victoria-logs:v1.52.0
ports:
- "9428:9428"
- "5514:5514"
- "5514:5514/udp"
volumes:
- "/srv/victoria:/victoria"
command:
- "-storageDataPath=/victoria/data/logs"
- "-syslog.listenAddr.tcp=:5514"
- "-syslog.listenAddr.udp=:5514"
Adding syslog listener is easy as adding some ports and command line options
After 11 years of development, MinIO has decided to move away from open source community, archiving it’s public Github repository.
So, let’s try Garage from DeuxFleurs, an S3-compatible distributed object storage service designed for self-hosting at a small-to-medium scale.
DeuxFleurs is a non profit association, founded un 2020, with the goal of building tools for a decentralized Internet.
For now, let’s stay on a single node, and add it to the docker compose stack.
Ollama version 0.30 has been released some time ago, bringing a major change: it now use llama.cpp instead of the internal GGML fork (see v0.30.0)
This has a big impact on my Strix Halo + Rocm setup
Using gemma4.31b, it runs 100% on the GPU
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gemma4:31b 6316f0629137 47 GB 100% GPU 262144 4 minutes from now
And using a simple question `what is json ?’ I obtained an answer at ~10 token per second.
total duration: 1m8.796615034s
load duration: 164.085088ms
prompt eval count: 17 token(s)
prompt eval duration: 205.756478ms
prompt eval rate: 82.62 tokens/s
eval count: 702 token(s)
eval duration: 1m8.1488854s
eval rate: 10.30 tokens/s
After upgrading to v0.30.5, ollama-rocm now detect both the CPU and the GPU
jui 15 19:18:57 phi25 ollama[1548]: device_info:
jui 15 19:18:57 phi25 ollama[1548]: - CPU : AMD RYZEN AI MAX+ 395 w/ Radeon 8060S (31727 MiB, 31727 MiB free)
jui 15 19:18:57 phi25 ollama[1548]: - ROCm0 : AMD Radeon 8060S Graphics (98304 MiB, 29071 MiB free)
And now, the modele is spread across the two devices
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gemma4:31b 6316f0629137 34 GB 57%/43% CPU/GPU 262144 4 minutes from now
And this has a major impact on perfomance, as the token per second is almsot devided by two.
total duration: 1m44.78409003s
load duration: 309.925333ms
prompt eval count: 17 token(s)
prompt eval duration: 770.637ms
prompt eval rate: 22.06 tokens/s
eval count: 689 token(s)
eval duration: 1m43.701536s
eval rate: 6.64 tokens/s
An issue about this is opened on github: #16462
How I run Ollama on the last addition to my homelab, the MS S1 Max from Minisforum featuring the Strix Halo processor from AMD, 128Gb unified memory and 2 SFP+ 10Gbe network interfaces.
Being a long time Debian user, I want to try out this declarative and reproductible system NixOS.
After installing NixOS with just console, I added a few packages, starting by ssh.
Extract from /etc/nixos/configuration.nix:
environment.systemPackages = with pkgs; [
amdgpu_top
bmon
htop
nvd
tmux
vim
];
Add a dedicated confuration file in /etc/nixos, /etc/nixos/ollama.nix:
For many years, I’ve ran my Unifi network controller with Docker Compose using included mongodb server.
But now it is time to change this. To externalize and upgrade it.
Until now, Unifi was deployed using the included MongoDB server.
unifi:
image: goofball222/unifi:10.0.160-ubuntu
hostname: unifi
user: unifi
restart: always
ports:
- 3478:3478/udp # STUN connection
- 6789:6789 # throughput measurement from Android/iOS app
- 8080:8080 # UAP/USW/USG to inform controller
- 8443:8443 # controller GUI / API
- 8880:8880 # HTTP portal redirect
- 8843:8843 # HTTPS portal redirect
- 10001:10001/udp # UBNT discovery broadcasts
environment:
- DB_MONGO_LOCAL=true
volumes:
- /srv/unifi/data:/usr/lib/unifi/data
- /srv/unifi/log:/usr/lib/unifi/log
- /srv/unifi/cert:/usr/lib/unifi/cert
# cd /srv
# ls -lh unifi/data/backup/
$ docker compose down unifi
# cd /srv
# cp -rp unifi/data/db mongounifi
Using the same version as in the Unifi container, to be upgraded later.
How to expose Prometheus metrics from a json blob returned by a server.
Here is a walk through, based on json retreived from an EthSwarm node.
Here is a sample for the status json, from the API documentation,
{
"overlay": "36b7efd913ca4cf880b8eeac5093fa27b0825906c600685b6abdd6566e6cfe8f",
"proximity": 0,
"beeMode": "light",
"reserveSize": 0,
"reserveSizeWithinRadius": 0,
"pullsyncRate": 0,
"storageRadius": 0,
"connectedPeers": 0,
"neighborhoodSize": 0,
"requestFailed": true,
"batchCommitment": 0,
"isReachable": true,
"lastSyncedBlock": 0,
"committedDepth": 0
}
ethswarm/status.go start with the package declaration and imports
package ethswarm
import (
"encoding/json"
"log"
"net/http"
"github.com/prometheus/client_golang/prometheus"
)
Since a few time, I have to wait two minutes on each reboot, waiting for a faulty systemd service: systemd-networkd-wait-online.service
server# journalctl --boot -u systemd-networkd-wait-online.service
Jun 22 13:38:00 server systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
Jun 22 13:40:00 server systemd-networkd-wait-online[472]: Timeout occurred while waiting for network connectivity.
Jun 22 13:40:00 server systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Jun 22 13:40:00 server systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Jun 22 13:40:00 server systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.
The service is linked to the network-online systemd target.
server# ls -l /etc/systemd/system/network-online.target.wants/
total 4
lrwxrwxrwx 1 root root 42 Mar 23 12:02 networking.service -> /usr/lib/systemd/system/networking.service
lrwxrwxrwx 1 root root 60 Apr 26 18:26 systemd-networkd-wait-online.service -> /usr/lib/systemd/system/systemd-networkd-wait-online.service
Reproduce the problem, running the command without any additional argument. Real time is 2 minutes and return 1.
server# time /usr/lib/systemd/systemd-networkd-wait-online ; echo $?
Timeout occurred while waiting for network connectivity.
real 2m0.236s
user 0m0.004s
sys 0m0.011s
1
Testing the commmand with extra argument, the command exit immediately and returns 0.
server# time /usr/lib/systemd/systemd-networkd-wait-online --timeout=2 -i enp2s0f0 ; echo $?
real 0m0.017s
user 0m0.013s
sys 0m0.004s
0