Portal - .easec

Arbeta med bestående lagring i Kubernetes

När jag har läst dokumentationen från Kubernetes, så har det varit lite svårt att förstå hur detta konfigureras. Så det är väl lika bra att gå igenom detta steg för steg.

Övergripande steg

1. Konfigurera lagring.
2. Skapa .yaml-fil för lagring  (ansvaret ligger på Ops). 
3. Skapa .yaml-fil för begäran (eng. claim) (ansvaret ligger på Dev).
4. Skapa .yaml-fil för pod som för lagringsdelen refererar til claim (ansvaret ligger på Dev).
5. Starta pod.

Steg 1. Konfigurera lagring

Detta beror på vilken typ av lagring som skall användas. I mina övningsexempel används både lokal lagring på nod (easec-linux2) och på NFS-server. Båda dessa kommer att behöva konfigureras. Kubernetes kan arbeta med en mängd olika typer av lagring och som finns både lokalt och i molntjänst.

Exemplet i denna blogg kommer att använda NFS-server. För att underlätta lite i kurs- och labbsammanhang har .easec tagit fram en docker-container för detta syfte. Dockerfile för denna container finns här: https://github.com/easec/nfs-server . I andra sammanhang är det alltid bäst att sätta upp en "riktig" NFS-server.

Förutsättningar: Docker installerat och Kubernetes uppsatt enligt .easec:s specifikationer. git installerat liksom nfs-utils  (på Ubuntu: sudo apt-get install nfs-kernel-server) på alla ingående maskiner.

På https://github.com/easec/Kubernetes finns alla .yaml-filer som refereras, klona dessa till din hemmakatalog med kommandot git clone https://github.com/easec/Kubernetes.git .

1. Öppna terminalfönstret och skriv in följande kommando och klicka på Enter efter varje rad:

    docker run -d --net=host \ 

    --privileged --name nfs-server \

    easec/nfs-server \

    /exports/data-0001 /exports/data-0002

    Container kommer att exponera två stycken kataloger, /exports/data-0001 och /exports/data-0002.

Steg 2: Skapa .yaml-fil för lagring (pv)

1. Om du har klonat mitt arkiv, förflytta dig till katalogen Kubernetes/persistent-volumes.

2. Öppna filen nfs-0001.yaml i din editor.

Lägg märke till att kapacitet anges under spec:, accessModes anger typ av access, i mitt kursmaterial har jag beskrivit de olika typerna av access som finns. På ett liknande sätt finns det även beskrivit de olika typerna av persistentVolumeReclaimPolicy som finns. Under nfs: anges anslutningsinformation till den maskin där docker-container med NFS-server körs och i detta fallet den första katalogen.

3. Applicera denna .yaml-fil med kommandot: kubectl create -f nfs-0001.yaml .

4. Öppna filen nfs-0002.yaml i din editor.

Denna .yaml-fil liknar den första, med två undantag. Det första undantaget är kapaciteten (i den första var den satt till 2Gi) som är satt till 5Gi och det andra undantaget är referens till katalog och i detta fallet pekar denna på den andra katalogen som exponeras av NFS-server.

5. Applicera denna .yaml-fil med kommandot: kubectl create -f nfs-0002.yaml .

6. För att se alla PersistentVolumes i klustret, använd kommandot kubectl get pv .

Steg 3: Skapa .yaml-fil för claim (pvc)

1. Öppna filen pvc-mysql.yaml i din editor.

2. Applicera denna .yaml-fil med kommandot: kubectl create -f pvc-mysql.yaml .

3. Öppna filen pvc-http.yaml i din editor.

Precis som tidigare fil (pvc-mysql.yaml) beskriver denna vad som begärs av eventuell pod som kopplas mot denna claim. I detta fallet kommer det att krävas att lagringen har möjlighet att exponera 1Gi.

4. Applicera denna .yaml-fil med kommandot: kubectl create -f pvc-http.yaml .

5. För att se alla claims i klustret, använd kommandot kubectl get pvc . När du har kört kommandot, kommer du att se att claim-http är associerat med nfs-0001 och claim-mysql är associerat med nfs-0002. Du kan även se den totala kapaciteten för respektive lagring.

Steg 4: Skapa .yaml-fil för pods

1. Öppna filen pod-mysql.yaml i din editor. 

Under sektionen containers kan du se att pod kommer att baseras på avspeglingen openshift/mysql-55-centos7, ett antal miljövariabler är definierade (i produktion används exempelvis Secrets för detta), monterar volym till katalogen /var/lib/mysql/data. Under sektionen volumes finns referens till claim-mysql.

2. Öppna filen pod-http.yaml i din editor. 

Under sektionen containers kan du se att pod kommer att baseras på avspeglingen nginx:alpine, port 80 kommer att exponeras, monterar volym till katalogen /usr/share/nginx/html. Under sektionen volumes finns referens till claim-http.

Steg 5: Starta pods

2. Starta pod-http med kommandot: kubectl create -f pod-http.yaml .

3. Använd kommandot kubectl get pods för att verifiera att dessa körs. Tänk på om du inte installerade nfs-utils (på Ubuntu: sudo apt-get install nfs-kernel-server) på noderna, kommer någon pod att stå läget att den skapas under längre tid. För att se vad som händer, kan du använda kommandot kubectl describe pod <namnet_på_denna_pod>, troligtvis har du ett felmeddelande att volym inte kan monteras. Installera nfs-utils och strax kommer du att se att pod är i läget Ready,

Extra: verifiera funktion

2. Ta reda på IP-adress för pod, genom att använda följande kommando: ip=$(kubectl get pod www -o yaml | grep podIP | awk '{split($0,a,":"); print a[2]}'); echo $ip .

3. Verifiera med kommandot curl $ip att texten du skrev in under punkt 1 visas.

4. Om du har webbläsare, kan du ansluta denna till pod och texten du skrev in under punkt  1 visas.

I .easec:s kurs arbetar du vidare med dessa pods.

Rensa

Använd stegen nedan för att rensa din miljö!

1. Använd kommandot kubectl delete pod www mysql för att plocka bort pods.

2. Använd kommandot kubectl delete pvc claim-http claim-mysql för att plocka bort pvc.

3. Använd kommandot kubectl delete pv nfs-0001 nfs-0002 för att plocka bort pv.

4. Använd kommandot docker stop nfs-server && docker rm nfs-server för att stänga ner docker-container och plocka bort denna.

Docker in Docker (DiD)

Det finns möjlighet att låta Docker container starta och köra en annan Docker container. Detta görs genom att köra en Docker Unix socket inuti en container. Socket är en endpoint på nätverket där information skickas mellan olika mjuvaror. Docker.sock är en Unix socket som ger möjlighet för Docker daemon, dockerd, att kommunicera med kommandoradsgränssnittet via REST API.

Socket blir som en fil, /var/run/docker.sock, eftersom det är en fil kan administratörer dela och köra docker.sock inuti container och använda den för att starta och kommunicera med denna. En container som kör docker.sock kan starta eller stoppa andra containers, skapa avspeglingar på värd eller skriva till värds filsystem.

Dock finns det några säkerhetsrisker med detta och det är viktigt att administratör är medveten om detta.

Risker med möjligheten

Docker.sock kommer att utöka attackytan för container och det kan bli ett sätt att kompromettera värd. Om en icke auktoriserad användare får tillgång till container som kör docker.sock, kommer hen att få rooträttigheter på värd och i Docker. Rootanvändare kan förändra värd och denna användare har även möjlighet att starta, stoppa eller exekvera vilket kommando i Docker som helst. Dessutom kan hen lyssna på eller ansluta till API, då denna person har tillgång till Docker socket.

Använda funktionen säkert

Detta bästa sättet att undvika dessa säkerhetsrisker, är att inte alls använda sig av docker socket. Men om organisationen måste använda sig av docker.sock, följ dessa rekommendationer:

• Innan du monterar docker.sock till container, funderar på information som denna container kommer att dela eller innehålla – ju mer känslig information, desto högre säkerhetsrisk. Tilldela bara tillgång för container till den information som den behöver genom att använda docker.sock. Som minsta åtgärd, sätt information i container till endast read-only, eftersom detta kommer att förhindra ickeauktoriserad användare att ändra informationen. Denna åtgärd kommer dock inte att förhindra att denna användaren från root-rättigheter på värd.
• För att sätta restriktioner på vad användare kan göra, slå på Transport Layer Security (TLS) eller använd sk authorization proxies. Docker kan också blockera tillgång till socket över http och tillhandahålla ytterligare funktioner för auktorisation och autentisering genom konfigurationer för rollbaserade rättigheter. Som ett tillägg kan du använda Docker Bench for Security, ett skript som automatiserar kontroll av container via riktlinjer från Center för Internet Security och rekommendationer för implementeringar av containers.

Alternativ för docker.sock

Det finns inte många direkta alternativ for funktionen, men genom att använda proxies kan säkerheten förhöjas.

HAProxy är en lastbalanserare för TCP och http som är öppen källkod. Administratörer kan sätta upp HAProxy för att lyssna på docker.sock och även för att stödja specificerade endpoints eller att ta bort  tillgången till docker.sock.

Ett annat alternativ är docker-proxy-acl, som är en Unix socket-proxy. Med denna produkt kan du låsa ner eller tillåta tillgång till endpoints och detta inkluderar containers, avspeglingar, volymer, händelser, arbetsuppgifter och nätverk. Docker-proxy-acl kan också förhindra att användare bygger egna Dockerfile där de kan lägga till instruktioner av misstänkt natur och på detta sätt få in dessa instruktioner i en avspegling som organisationen använder sig av.

Produkter som nämns i denna artikel:

Docker Bench Security: https://github.com/docker/docker-bench-security

HAProxy: http://www.haproxy.org/

docker-proxy-acl: https://github.com/titpetric/docker-proxy-acl

Åtta principer för Continuous Delivery

1.     Process för release/produktionssättning måste kunna repeteras och måste vara pålitlig.

2.     Automatisera allting. Manuell produktionssättning kan aldrig beskrivas som repeterbar eller pålitlig.

3.     Om något är svårt eller jobbigt, gör det ofta. Om du gör något som är arbetsamt oftare, leder detta till att du troligtvis automatiserar det eller hittar dellösningar. Exempelvis tycker du det är arbetsamt att implementera schema för databas, brukar detta leda till att du inte gör detta så ofta. Det du egentligen skulle göra, är att göra detta en gång om dagen istället för kanske en gång i månaden.

4.     Ha allting i source control. Detta kanske låter lite konstigt idag. Och vem har inte allt i source control? Eller?

5.     Gjord, eller done, betyder släppt eller released. Detta handlar om ägandeskap för projektet, efter detta steg har ägandeskapet överförts till användare. Utvecklareteamet kontrollerar kontinuerligt funktion i produktion.

6.     Bygg in kvalitet! Ta tiden som krävs för att fundera på hur du kan mäta kvalitet för programkod. Projekt som har ett bra sätt att mäta kvalitet (unit test, sätt att koda, regelverk, mätning komplexitet) kommer att vara bättre än projekt som inte använder detta, dessutom kommer det långsiktigt att vara lättare att underhålla.

7.     Alla har ett ansvar för processen för release. Ett program som körs på utvecklarens dator, kommer inte att generera pengar för företaget. På ett liknade sätt så kommer ett projekt utan någon plan för utrullning, att aldrig bli släppt och återigen kommer inga pengar in till företaget. Företag får in pengar när produkter släpps till kunder och därför skall processen vara av intresse för alla. Utvecklare skall utveckla sina projekt med tanke på hur utrullning skall ske. Projektledare skall planera projektet med tanke på utrullning. Testare skall förutom att testa själva programmet, lägga fokus på att testa utrullningen. Tester av den sistnämnda typen skall vara automatiserade och inbyggda i själva utrullningen.

8.     Förbättring – pågående process. Luta dig inte tillbaka och vänta på att ditt system kommer att bli gammalt och omöjligt att underhålla. Förbättringsprocessen pågår alltid och blir mycket lättare att genomför om du redan har tänkt på detta.

Dessa åtta principer leder till dessa fyra praxis:

1.     Bygg exekverbara filer endast en gång. Exekverbara filer skall lagras på en plats och denna plats skall endast vara nårbar av mekanism för utrullning.

2.     Använd exakt samma mekanism för utrullning till varje miljö.

3.     Testa din utrullning. Även om utrullningen har varit lyckad, behöver detta inte innebära att allting verkligen finns på plats. Skriv ett test som kontrollerar så att allting finns där det skall vara. Exempelvis jämför från en lista över filer så att dessa finns, eller jämför konfiguration utifrån en lista, i denna lista finns den förväntade konfigurationen, denna jämförs med hur det verkligen ser ut.

4.     Om något fallerar, stoppa allting! Ta bort utrullningen och starta om processen igen, patcha inte eller förändra någonting, istället gör du en rollback på utrullningen, fixa problemet på ett ordentligt sätt. Gör aldrig förändringar i ett system som lever! Inte ens om det är ont om tid. Detta leder alltid till en dålig kvalité på din programkod.

Ny kurs från .easec, Orkestrering i Docker.

Två dagars kurs med följande innehåll:

Docker

Modulen ger bakgrundsinformation om Docker och kunskaper hur du installerar Docker.

Lektioner: Bakgrund, Docker bas och Arkitektur

Kommando

I denna modul får du lära dig användbara kommando för att arbeta med Docker och containers.

Lektioner: Kommando och Hantera container

Dockerfile

Dockerfile är en vital funktion för att skapa avspeglingar, men används även av många andra funktioner i Docker. I denna modul tittar vi på grunderna i Dockerfile.

Lektioner: Skapa avspegling och Dockerfile

Orkestrering

I denna modul tittar vi på Docker Compose, Docker Swarm, Docker Machine och Docker Cloud. Alla dessa är inbyggda verktyg för att hantera orkestrering av Docker. I modulen nämns även andra tredjepartstjänster.

Lektioner: Docker Compose, Docker Swarm och Docker Machine

Kubernetes

I denna modul tittar vi på och arbetar med Kubernetes.

Lektioner: Koncept och arkitektur, Deklarativ och imperativ, Nätverksmodell och Första kontakt med kubectl.

På utbildningscenter i Sverige eller via molnet!

PDF beskriver hur du använder Windows PowerShell för att installera och konfigurera NAT på Windows Server 2016 Core 1809.

PDF hittar du här: https://stordevsumj.blob.core.windows.net/easec/Konfigurera_router_pa_Windows_Server_Core.pdf

Det är ingen hemlighet att .easec gillar Docker, varför inte kombinera släktforskning med Docker? Pdf beskriver hur du tillverkar container i Docker med verktyget Webtrees. Webtrees är ett opensource projekt för släktforskning.

Vill du se hur det ser ut, gå till: http://famjohannesson.se . 

Hur jag har gjort, finns beskrivit här: https://stordevsumj.blob.core.windows.net/easec/Skapa_avspegling_for_Webtrees.pdf

Denna nya kurs har fokus på Windows Server 2016/2019, men Linux finns med på ett hörn.

Direktlänk till kursen: https://portal.easec.se/moodle/enrol/index.php?id=19

.easec:s kursmiljö uppdaterad till Windows Server 2019 1809 och Windows 10 1809. 

Azure Container Registry

 Du kan implementera ditt egna privata förråd av container genom att använda Container Registry service i Azure. Detta ger möjlighet till att skapa och underhålla din egen samling av avspeglingar för dina Docker containers, samtidigt som du kan dra nytta av fördelarna med plattformen för Azure, när det gäller tillgänglighet, prestanda och flexibilitet.

Du kan läsa mer här: https://stordevsumj.blob.core.windows.net/easec/Skapa_Container_Registry_service.pdf