Ok så jag vet inte om ni stött på dessa nyhetsrubriker,
Jaha och Stefan som pratar så mycket om just dessa två, hur bra dom gifter sig osv osv.
Är han lika outdated som hans gråa hår tycks indikera 😉 ?
Generellt är jag nog det – outdated alltså, men i detta fall med Kubernetes och Docker : NEJ. Att Kubernetes inte stödjer Docker längre är inte alls så dramatiskt som man tror. Vi kommer fortsätta använda Kubernetes och Docker på samma sätt som idag.
Jag ska förenkla: den enda praktiska effekten är att det inte går att bygga images INIFRÅN en container INUTI klustret. Fattar ni inte vad jag menar? Nej, då påverkas ni inte. Så här: vissa företag flyttar in hela sin Build Pipeline IN i sitt eget kluster. Istället för att använda tex Azure Devlops Build Pipelines, eller Gitlab/AWS ditos. Det är i stort sett endast detta scenario (när man inifrån sitt eget kluster försöker bygga en docker image ) – det kommer inte gå att göra
För att förklara: “Docker Build”-kommandot bygger INTE Docker images som man kan tro (jag sa det tom två rader upp). Det finns inget som heter “Docker image”. Det skapas en OCI-compliant (standard) image och det är den som vi slänger in i det vi (slarvigt igen) kallas för Docker image Registry. Och som sen Kubernetes använder för att starta containers.
Med andra ord: kör ni externa buildsystem (inte inne i ett eget Kubernetes-cluster) är dessa rubriker sannolikt inget att bry sig om alls. Bygger ni images inuti ert kluster – då är ni så långr fram att ni redan vet om Kaniko etc – alternativ till “docker build”
Eller varför inte Podman från Redhat som är ett CLI som i stort sett gör ALLT som docker gör
Ska försöka återkomma till Podman – jag kommer sannolikt byta ut Docker mot just Podman i min egen toolchain
Ja förutom grunderna som
– Docker images i botten (ja vilka containers som helst i stort sett)
– infrastructure by code (hela setupen definieras i YAML-filer som källkodshanteras = Enkelt att byta leverantör )
– fullständig automatisk hantering med scaling (köra på en eller flera )
så är en cool sak som ofta förbises av de som inte förstår Docker är hur du kan köra batchjobb etc i separata isolerade containers (eftersom Docker-containers kan startas upp på millisekunder – jämfört med en virtuell maskin som tar minuter!):. Dvs: istället för att ha en batchmaskin som ni kladdar ner med diverse tredjepartsprodukter, jag tänker på S3 klient, Python, osv osv så skapar du specialsydda batchcontainers – per unik uppsättning, och i fallet med Kubernetes så ingår själva cronjobscheduleringen.
Containers är det “nya batch-filer, ps1+sh osv osv” och parametrar skickar du genom environment-variabler istf kommandoradsparametrar.
Ok…lugn och fin: massa kod och YAML på g. Men det finns ett UI, jag visar det längst ner!
Min SQL Server backup setup
1. Jag har skapat en Docker image. Den utgår från Alpine Linux och jag konfar den med både s3cmd (Python) och SQL Server klient för Linux (dvs sqlcmd)
FROM alpine:3.11
RUN apk update
RUN apk add python py-pip py-setuptools git ca-certificates
RUN pip install python-dateutil
RUN git clone https://github.com/s3tools/s3cmd.git /opt/s3cmd
RUN ln -s /opt/s3cmd/s3cmd /usr/bin/s3cmd
WORKDIR /opt
ADD ./files/mine /opt/s3cfg
ADD ./files/main.sh /opt/main.sh
ADD ./files/sqlserver.sh /opt/sqlserver.sh
# Main entrypoint script
RUN chmod 777 /opt/main.sh
RUN chmod 777 /opt/sqlserver.sh
# Folders for s3cmd optionations
RUN mkdir /opt/src
RUN mkdir /opt/dest
ARG MSSQL_VERSION=17.5.2.1-1
ENV MSSQL_VERSION=${MSSQL_VERSION}
RUN apk add --no-cache curl gnupg --virtual .build-dependencies -- && \
# Adding custom MS repository for mssql-tools and msodbcsql
curl -O https://download.microsoft.com/download/e/4/e/e4e67866-dffd-428c-aac7-8d28ddafb39b/msodbcsql17_${MSSQL_VERSION}_amd64.apk && \
curl -O https://download.microsoft.com/download/e/4/e/e4e67866-dffd-428c-aac7-8d28ddafb39b/mssql-tools_${MSSQL_VERSION}_amd64.apk && \
# Verifying signature
curl -O https://download.microsoft.com/download/e/4/e/e4e67866-dffd-428c-aac7-8d28ddafb39b/msodbcsql17_${MSSQL_VERSION}_amd64.sig && \
curl -O https://download.microsoft.com/download/e/4/e/e4e67866-dffd-428c-aac7-8d28ddafb39b/mssql-tools_${MSSQL_VERSION}_amd64.sig && \
# Importing gpg key
curl https://packages.microsoft.com/keys/microsoft.asc | gpg --import - && \
gpg --verify msodbcsql17_${MSSQL_VERSION}_amd64.sig msodbcsql17_${MSSQL_VERSION}_amd64.apk && \
gpg --verify mssql-tools_${MSSQL_VERSION}_amd64.sig mssql-tools_${MSSQL_VERSION}_amd64.apk && \
# Installing packages
echo y | apk add --allow-untrusted msodbcsql17_${MSSQL_VERSION}_amd64.apk mssql-tools_${MSSQL_VERSION}_amd64.apk && \
# Deleting packages
apk del .build-dependencies && rm -f msodbcsql*.sig mssql-tools*.apk
# Adding SQL Server tools to $PATH
ENV PATH=$PATH:/opt/mssql-tools/bin
RUN apk add --no-cache curl
RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
RUN install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
WORKDIR /
CMD ["/opt/sqlserver.sh"]
Dvs kör en backup på min Sql Server (allt inom ${}skickar jag ju som environmentvariabel)
Jag kopierar sedan ner backupfilen till denna container (/opt/src) – och skönt att slippa konfa NFS eller whatever för delade diskar, jag utnyttjar det faktum att både containarna tillhör samma Kubernetes-kluster = kubectl kan flytta data.
3. Sen är det bara att S3 synka /opt/src med min S3 bucket vars configjag styr med environment-variabler också. Den koden visar jag dock inte här men googla S3CMD
5. Sen skapar vi kopior av Cronjobbet för alla databaser vi vill backa
Ok. Jobbigt?
6. Jamen lite UI då. Med Kubernetes Dashboard kan man administrera sitt kluster grafiskt – och här har vi våra jobb och kan kontrollera status, loggar etc etc
Här kommer en liten genomgång av hur mitt Kuberneteskluster ser ut i produktion. Jag kommer återkomma med mer angående fördelar/nackdelar/vad jag kommer göra annorlunda nästa gång etc etc
Det kluster jag beskriver här gäller de sajter jag kör rörande min kursverksamhet.
systementor.se
kursregistreringar, nyheter
MS SQL Server
.NET 5.0
aspcode.net
online kurser
MS SQL Server
.NET 5.0
– massa content utanför databas också = bilder, zippfiler, pdf:er etc etc
test.aspcode.net
sajt för examinering, tester både för aspcode.net studenter men också utifrån
MS SQL Server
.NET 5.0
– massa content utanför databas också = bilder, zippfiler, pdf:er etc etc
blog.systementor.se
Denna sajt
WordPress
MySQL
PHP
MUST HAVES:
webfarm
varje sajt ska köras på minst tre noder för deployment utan nedtid
SSO
single signon mellan aspcode.net och test.aspcode.net samt möjlighet att utöka
Rimlig kostnad
ja, Azure är billigt. Om man bortser från: blue/green web deployment med deras teknik (slots) kräver ju standard eller premium plan. En endaste SQL Server databas är billig (från 50kr/mån). Men jag behöver 4-5 stycken och dessutom gånger 2 (stage environment)
Min kedja från kod -> sajt
Jag kodar i Visual Studio 2019 Community Edition. Lokal SQL Server + MySQL (men startar dessa on demand som docker images). Jag har också Redis i en docker image när jag utvecklar lokalt
Jag pushar kod till Github alt. Azure Devops. Jag har i Azure Devops Build pipelines som triggas och bygger Docker image (alla mina .NET sajter kör jag på Linux. Billigt och resurssnålt) och pushar till mitt egna
docker image registry (ligger inuti mitt Kubernetes-kluster)
Manuell verifiering innan jag via kommandoraden deployar med “kubectl rollout”. Denna kommer ta ur en nod i taget och uppdatera så tjänsten aldrig tas ned vid deploy.
Så det coola med Kubernetes (ja för jag kör såklart det som orkestrering) är att det fungerar som min admin-slav. Dag som natt. Dvs jag säger till Kubernetes tex, denna service (sajt) vill jag köra på tex 3 noder (replicas nedan)
Och sen monitorerar min snälla Kubernetes-slav allt och ser till att så är fallet, även om en instans går ner osv osv
Ok, så i mitt Kubernetes-kluster kör jag:
en lastbalanserare
nginx ingress controller
samt följande allt på (Linux) Docker images
– tre instanser systementor.se .NET 5.0
– tre instanser aspcode.net .NET 5.0
– tre instanser test.aspcode.net .NET 5.0
– en instans registry admin UI – tror det är Ruby faktiskt!
– en instans registry (japp motsvarande hub.docker.com – fast privat och närmare MINA noder)
– en instans MS SQL Server
– en instans MySQL Server
– en backup docker image – körs som cronjob on demand – kör backup på SQL-servrarna och pushar backup-filerna till
Backblaze B2 (S3 kompatibelt)
Var?
Jag har valt DigitalOcean som provider för Kubernetes-klustret, Backblaze B2 för lagring, och sen har jag fortfarande (fasar ut eftersom) lite Azure Blob Storage som ligger och skvalpar
Kostnaden för motsvarande setup i Azure för webbsajter och databas hamnar minst på 6 gånger mer. Iofs kan man få man allt i Azure helt managed men med Kubernetes och schemalagda jobb så löses och autokorrigeras ganska mycket