Portal - .easec

.easec kommer att publicera ett antal artiklar där konfiguration av Kubernetes i drift beskrivs. 

De olika delarna:

Del 1: Certifikat och klientverktyg. https://portal.easec.se/moodle/blog/index.php?entryid=39

Del 2: HA-Proxy. https://portal.easec.se/moodle/blog/index.php?entryid=40

Del 3: Installera och konfigurera etcd. https://portal.easec.se/moodle/blog/index.php?entryid=41

Del 4: Installera master. https://portal.easec.se/moodle/blog/index.php?entryid=44

Del 5: Installera worker. https://portal.easec.se/moodle/blog/index.php?entryid=45

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.

Watchtower  är ett program som övervakar dina körandes containers för förändringar av avspeglingen. När du trycker på en uppdatering till ditt Docker-register, upptäcker Watchtower ändringarna och drar ner den nya kopian av avspeglingen. Den startar sedan om container med den avspeglingen med samma startalternativ som originalet.

Låt oss till exempel säga att du har en containerapplikation som heter min-app som körs med en portkoppling på 8090: 3000. Ditt team använder CI/CD för att lansera dagliga uppdateringar av applikationen. När din iteration är klar märker du avspegling och skicka upp denna till registret. Watchtower har konfigurerats för att kontrollera registret var 30: e sekund. När 30-sekunders iterationen är klar, upptäcks förändringarna i avspeglingen och kommer att hämta hem den nya avspeglingen. Watchtower stänger sedan graciöst container för min-app och startar sedan om den med den nya avspeglingen med samma portkopplingar

För att allt detta ska fungera måste Watchtower ha tillgång till Docker API. När du skapar container för Watchtower måste du montera /var/run/docker.sock som en volym till denna.

Arbeta med Watchtower

1.     I terminalfönstret, skriv in följande kommando och klicka på Enter:

                docker run -d \

                --name watchtower \

                --restart always \

                -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower \

                -i 30

2.     Skapa projektkatalog och förflytta dig till denna.

3.     Skapa enkel webbsida med namnet index.html:

             <html>

                     <header>

                              <title>Min webbsida</title>

                    </header>

             <body>

                               Min webbsida.

            </body>

           </html>

4.     Skapa Dockerfile med följande innehåll:

          FROM nginx

          COPY index.html /usr/share/nginx/html/index.html

          WORKDIR /usr/share/nginx/html

5.     Skapa avspegling med följande kommando:

          docker build -t <ditt_användarenamn_på_Docker_Hub>/watch_nginx -f Dockerfile .

6.     Skicka avspegling till Docker Hub med följande kommando:

          docker push <ditt_användarenamn_på_Docker_Hub>/ watch_nginx

7.     Starta container med följande kommando:

         docker run -d --name min_webb_sida -p 80:80 --restart always <ditt_användarenamn_på_ Docker_Hub>/watch_nginx

8.     Öppna webbläsare och surfa till localhost, din sida skall visas.

9.     Redigera index.html enligt följande:

          <html>

                     <header>

                               <title>Min webbsida</title>

                     </header>

            <body>

                               Min fina webbsida. Gillar du den?

            </body>

            </html>

10.     Skapa ny avspegling med följande kommando:

              docker build --no-cache -t <ditt_användarenamn_på_Docker_Hub>/watch_nginx -f Dockerfile .

11.     Skicka avspegling till Docker Hub med följande kommando:

          docker push <ditt_användarenamn_på_Docker_Hub>/ watch_nginx

12.     Återgå till webbläsare, gör refresh på sidan. Efter ca 30 sekunder får du ingen kontakt med sidan. Gör en ny refresh och det nya innehållet visas. Container som startas om med förändringen.

Tack till alla 435 deltagarna på någon av kurserna som .easec, aclc och Linuxkurser har arrangerat i klassrummet och på Internet!

DirectAccess har funnits i ett antal år, men numera är Microsoft på väg att flytta fokus mot Always On VPN. Teknikerna erbjuder båda en sömlös och transparant fjärrtillgång som alltid är tillgänglig. Always On VPN har ett antal fördelar över DirectAccess när det gäller säkerhet, autentisering, hantering och stödfunktioner.

Säkerhet

DirectAccess tillhandahåller full nätverksanslutning när klient fjärransluter. Funktionen saknar inbyggda funktioner för att kontrollera anslutning. Det finns en möjlighet att sätta restriktioner tillgång till externa resurser genom att sätta brandvägg mellan server för DirectAccess och lokalt nätverk, men denna policy kommer att appliceras på alla anslutna klienter.

Windows 10 Always On VPN finns funktioner för att finmaskigt filtrera trafik. Där Direct Access tillhandahåller tillgång till interna resurs vid anslutning, ger Always On VPN en möjlighet för administratörer att på olika sätt sätta restriktioner för anslutningar mot interna resurser. Filter kan appliceras baserat på användare eller grupper. Exempelvis kan användare på marknadsavdelning bara komma åt denna avdelnings servrar.

Autentisering och hantering

DirectAccess inkluderar stöd för stark autentisering av användare med smarta kort eller lösningar för One Time Password (OTP). Dock finns det ingen möjlighet att tilldela tillgång baserat på konfiguration av enhet eller hälsa, eftersom denna funktion har tagits bort i Windows Server 2016. Som tillägg kräver DirectAccess att både klient och server är ansluten till domän då konfiguration sätts genom group policy i Active Directory.

Windows 10 Always On VPN inkluderar stöd för “modern authentication and management”, vilket ger som resultat bättre säkerhet. Klienter som använder Always On VPN kan vara anslutna till domän i Azure Active Directory och villkorsbaserad tillgång kan användas. ”Modern authentication” stödjer även Azure MFA och Windows Hello for Business. Funktionen hanteras av lösning för Mobile Device Management (MDM) såsom Microsoft Intune.

Prestanda

DirectAccess använder IPsec med IPv6, som måste kapslas in i Transport Layer Security (TLS) för att routas över ett publikt IPv4 Internet. IPv6 trafik kommer att översättas till IPv4 av DirectAccess server. Prestanda för DirectAccess accepteras oftast om klienter har en anslutning till Internet som är pålitlig och med hög kvalite. Dock om anslutningen är dålig, kommer detta att innebära dålig prestanda eftersom det finns flera lager av inkapsling och översättning.

För Windows 10 Always On VPN används vanligvis IKEv2. Detta protokoll erbjuder den bästa säkerheten och prestanda när jämförelse sker med TLS-baserade protokoll görs. Som ett tillägg så bygger inte funktionen på samma sätt som DirectAccess på IPv6. Eftersom inte flera lager av inkappsling och översättning används, kommer prestanda alltid att bli bättre.

Stödfunktioner

DirectAccess är en lösning från Microsoft som måste installeras på server som använder sig av Windows och Active Directory. Funktionen kräver även Network Location Server (NLS) så att klienter kan räkna ut om de finns på ett lokalt nätverk eller inte. Tillgängligt för NLS är kritisk och att försäkra sig att funktionen är tillgänglig kan vara en utmaning speciellt för större organisationer.

Dokumentet beskriver hur du arbetar med Windows 10 Autopilot. Dokumentet utgår ifrån .easec:s kursmiljö med virtuell maskin som innehåller Windows 10 Enterprise Edition och att du har en prenumeration för Microsoft Intune.

Tidig dator ålder

På 60-talet var det inte så vanligt med datorer, då kostnaden för dessa var väldigt höga. Bara för att hyra en dator var kostnaden alldeles för höga för att de skulle vara vanliga för de flesta företagen.

Ett behov och att lösa detta behov är en drivkraft för utveckling, så också inom datorvärlden. De tidigaste datorerna vara dedicerade för en specifik arbetsuppgift och det kunde ta dagar, t om veckor att köra ett jobb. Detta ledde fram till utvecklingen av virtualisering. Utvecklingen leddes av tanken att kunna dela dators resurser  med många användare på samma gång.

När skapandet av centraliserad dator kom, så var detta de första tecknen på virtualisering. Under 60-talet var flera terminal ansluten till en större central dator vilket möjliggjorde att arbetet kunde utföras från en central plats. Att arbeta med en central plats för dator, gav möjlighet att från denna plats kontrollera all bearbetning från en central plats, om en terminal skulle sluta att fungera, kunde användare gå till en annan terminal och logga på denna för att fortsätta sitt arbete. Dock fanns det fortfarande några negativa sidor. Exempelvis om användare kraschade den centrala datorn, så gick systemet ner för alla användare. Detta ledde fram till datorer inte bara behöver kunna separera användare utan även processer som körs i systemet.

Virtualisering

1973 publicerade Gerald J. Popek och Robert P. Goldberg rapporten Formal Requirements for Virtualizable Third Generation Architectures, där de beskriver tre typer av virtualisering:

-         Type 0, där virtualisering görs direkt på hårdvara.

-         Type 1, där virtualiseringstekniken innehåller ett operativsystem.

-         Type 2, där virtualiseringstekniken kräver att det redan finns ett operativsystem.

Detta dokument ligger till grund för all virtualisering som företag och organisationer arbetar med idag och blir också, kan man säga, en delning mellan virtualisering och teknik för att särskilja applikationer eller tjänster.

chroot

1979 togs det ett annat steg med utvecklingen av kommandot chroot (change root). chroot används för att skapa en delad men isolerad miljö. Kommandot ger en möjlighet till att ändra root-miljö för en körandes process tillsammans med dess barn (children).

Detta gav en möjlighet att isolera systemprocesser till egna segregerade filsystem så att tester kunde utföras utan att påverka den globala miljön för systemet. I mars 1982 la Bill Joy till kommandot i den sjunde versionen av Unix.

Solaris Zones

2004 lanserades Solaris containers, Solaris containers skapar en full miljö för applikationen genom att använda Solaris Zones. Med zones får applikationen tillgång till användare, processer, filsystem och hårdvara på systemet. Dock kan applikationen bara se var som finns i sin egen zon.

jail

I syftet att förstå containers, får vi förflyttas oss framåt i tiden lite, till 1990-talet, när Bill Cheswick arbetade med att försöka förstå hur en cracker använde den tid som denna hade på sig i ett system. I sin undersökning byggde Cheswick en miljö som tillätt honom att analysera cracker:s tangentnedslagningar och för att lära sig dennes teknik. Hans lösning var att använda en miljö skapade av chroot och som var modifierad. Resultatet av Cheswick:s studier ledde fram till kommandon jail i Linux.

I mars 2000 (närmare bestämt 4 mars 2000), introducerade FreeBSD kommandot jail i sitt operativsystem. Även om kommandot liknande chroot så inkluderades ytterligare funktioner såsom möjlighet att isolera filsystem, användare, nätverk, etc. FreeBSD jail ger möjlighet till att tilldela IP-adress, konfigurera skräddarsydda mjukvaruinstallation och modifiering för varje miljö. Dock till en kostnad då funktionalitet för mjukvaran påverkades.

control groups (cgroups)

2006 lanserade ett antal utvecklare på Google process containers. Dessa var designade för isolering och begränsningar för resurnyttjande för process. 2007 döptes process container om till control groups (cgroups) för att undvika namnkollision med ordet containers.

LXC

2008 lades cgroups till i Linux kernel 2.6.24 och som i sin tur ledde till att projektet LXC startades. LXC står för Linux Containers och ger en möjlighet till virtualisering på operativsystemsnivå, genom att tillåta att ett antal isolerade Linuxbaserade miljöer (containers) körs på delad Linux kernel. En och var av dessa containers har sina egna processer och nätverk.

LMTCFY

2013 ändrade Google på konceptet containers, genom att göra sitt projekt Let Me Contain That For You (LMTCFY) till ett öppet projekt. Genom att använda LMTCFY, kunde applikationer skrivas för container och med möjlighet att skapa och hantera sina egna undercontainers. Arbetet på LMCTFY stoppades 2015 och Google beslöt att arbetet skulle läggas i projektet libcontainer, som Docker hade startat.

Start för Docker

"The technology was not accessible/useful for developers, containers were not portable between different environments, and there was no ecosystem or set of standard containers," Docker's chief executive Ben Golub.

Docker lanserades som ett open-source projekt 2013. Docker tillhandarhåller möjligheten att paketera containers så att de kan flyttas från en miljö till en annan. Från början använda Docker LXC-teknologien, men 2014 ersattes LXC med libcontainer, vilket ger en möjlighet för container att arbeta med Linux namespaces, libcontainer control groups, capabilities, säkerhetsprofiler i AppArmor, gränssnitt för nätverk och regelverk för brandvägg. Docker bidrar till community med globalt eller lokalt förråd kallat för registry, ett restful API och CLI-klient. Senare har även Docker implementerat hanteringssystem för kluster med namnet Docker Swarm och ett antal andra produkter för orkestrering.

.easec har ett stort antal kurser där du får lära dig allt om Docker och containers, se gärna vidare på https://portal.easec.se/moodle/course/index.php?categoryid=7

Gartner  förutspår att när vi når 2020, kommer mer än 50 % av de global organisationerna att produktions köra applikationer i containers, idag är det mindre än 20 % av dessa globala organisationer som kör containers i produktion. 

Enligt 451 Reseach var marknaden $762 miljoner förra året och kommer att öka 3.5 gånger till $2.7 billion är 2020. 

.easec tillsammans med Edument AB anordnar Docker Birthdayparty den 2 april 2019 i Malmö, välkommen du med och lär dig mer om detta. Både .easec och Edument AB har lång erfarenhet av Docker.

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.