[K8s] Migratie van dockershim

In onderstaand schema zie je als eerste een K8s configuratie die gebruik maakt van dockershim. In het schema daaronder staat een K8s configuratie zonder docker, maar met de CRI-containerd

Dockershim vs. CRI with Containerd

Dockershim is een shim waarmee de gehele docker engine gebruikt kan worden voor de container images. In Kubernetes release v1.24 is de dockershim verwijderd en wordt gebruik gemaakt van CRI-containerd. (of CRI-Dockerd)

Container images die gemaakt zijn met docker werken nog steeds prima met containerd en dus geen probleem voor images die reeds aanwezig zijn.

Lees verder

Toevoegen van GitLab-Runner aan project

Installeer eerst gitlab-runner op een host.

Gebruik daarna de volgende opties waarbij de token uit het project -> Settings ->CI/CD -> Runners gehaald kan worden.

gitlab-runner register -n \ 
  --url https://gitlab.digitalinfo.nl/ \
  --registration-token <de token uit de settings>  \
  --executor docker \
  --description "Docker Runner" \
  --docker-image "docker:stable" \
  --docker-privileged

[GitLab] Toevoegen van GitLab-Runner aan project

Installeer eerst gitlab-runner op een host.

Gebruik daarna de volgende opties waarbij de token uit het project -> Settings ->CI/CD -> Runners gehaald kan worden.

gitlab-runner register -n \ 
  --url https://gitlab.digitalinfo.nl/ \
  --registration-token <de token uit de settings>  \
  --executor docker \
  --description "Docker Runner" \
  --docker-image "docker:stable" \
  --docker-privileged

Tune de opdrachtprompt

De Opdrachtprompt gestart met cmd.exe, kan aangepast worden middel seen Autorun bestand dat uitgevoerd wordt bij opstarten van de command prompt. Dit is een registry-instelling die staat in HKCU\SOFTWARE\Microsoft\Command Processor en is een string genaamd ‘Autorun‘. Hierin kun je aangeven welk bestand je wilt starten, bijvoorbeeld environment.cmd:
Hierin kun je bv. de volgende commando’s plaatsen: Lees verder

De witness in een cluster

Windows clustering service is een uitermate goed product dat gebruikt kan worden om een ‘high availability’ configuratie te maken. Deze oplossing wordt dan ook veel gebruikt bij SQL-, IIS- en Exchange-servers. Indien één van de servers down gaat, zal de cluster bereikbaar blijven via één (of meer) van de andere members van de cluster. Een voorwaarde voor een cluster om ‘on-line’ te zijn is dat er een meerderheid van de members beschikbaar moet zijn. Dit is dan ingesteld in de zogenaamde ‘quorum’ configuratie. Nu is dat bij een oneven aantal servers geen probleem maar wat als je een even aantal servers hebt? In dat geval dient er een ‘witness’ aanwezig te zijn die een ‘vote’ mag uitbrengen om een meerderheid te behalen. Een witness kan een disk (‘disk witness’) zijn of zelfs een bestands-server. (‘file share witness’)

Zo kun je bijvoorbeeld een Exchange DAG maken met het volgende Exchange Powershell commando:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer SRV3 -WitnessDirectory C:\DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.1

Hierbij wordt server SRV3 gebruikt als File Share Witness. Indien gewenst kan zelfs de FSW in Windows Azure ingesteld worden.

exchDAG

Voorkom dat de monitorservice nginxlogs vol laat lopen

Webservers gebaseerd op nginx houden een log bij, tenzij logging geheel is uitgeschakeld, genaamd de access_log. De monitorservice die ik gebruik is Pingdom en zoals veel andere monitor-services doet deze een check op de website voor performance statistieken. Deze check is een connectie en komt derhalve in de access_log.

Om dat te voorkomen heb ik in de vhost config file de volgende regel opgenomen in location /

if ($http_user_agent = “Pingdom”) {

   access_log off;

}

Na een restart van Nginx zijn er geen Pingdom access regels meer.