Docker compose

System och dess infrastruktur

Nästan alla system har beroenden till någon form av infrastruktur. Med infrastruktur menar jag t.ex. databaser, webbservrar och meddelandebussar. Att köra ett sådant system lokalt, när du utvecklar, kan vara frustrerande om du inte har rätt verktyg. Ett vanligt sätt att arbeta är att gå mot en installerad miljö avsedd för test.

Jag tänker inte gå in djupare på problem som kan uppstå när ett team skall samsas om en central miljö för att tillgodose sina infrastrukturella behov, men sammanfattningen i punktform här nedan visar på eventuella problem.

• Inloggningsuppgifter behövs sannolikt på ett eller annat sätt
• Samsas om testdata
• Nätverksåtkomst till servrar
• Svårt att jobba offline
• M.m.

Containers som t.ex. Docker blir allt vanligare i branschen. Dock tycker jag inte att det slagit igenom så mycket som jag skulle önska – vilket är synd eftersom det finns en stor potential med användandet av containrar. En container är ett paket av all kod, inklusive alla beroenden, som behövs för att köra ett system. Ett beroende är t.ex. operativsystemet (Linux, Windows, med mera) och körtidsmiljön (.NET runtime, med mera). Det finns en uppsjö av fördefinierade “Docker containers” att ladda hem. Det är bland annat dessa containrar som du kan dra nytta av i din lokala miljö. Du kommer inte längre behöva koppla upp dig mot en SQL Server eller annan databas i en miljö som du inte kontrollerar. I stället skräddarsyr du miljön lokalt.

Docker compose

Som nämnt tidigare arbetar man ofta mot en infrastruktur med flera rörliga delar. Det kan vara en databas, en meddelandekö, eller något annat. Du kan lätt beskriva din infrastruktur via ett verktyg som heter “Docker compose”. Docker compose är ett verktyg för att stödja flera containrar samtidigt. Jag kommer i det här exemplet bygga upp min infrastruktur med följande komponenter:

• Redis cache
• Redis commander (UI för Redis)
• RabbitMQ
• RabbitMQ management portal

Konfigurera Docker compose

Konfigureringen sker via en yml-fil där infrastrukturen beskrivs. I vårat fall ser den ut så här:

version: '3'
services:
  redis:
    image: "redis"
    ports:
    - "6379:6379"
  redis-commander:
    image: rediscommander/redis-commander:latest
    restart: always
    environment:
    - REDIS_HOSTS=local:redis:6379
    ports:
    - "8081:8081"
  rabbitmq:
    image: "rabbitmq:3-management"
    ports:
    # The standard AMQP protocol port
    - '5672:5672'
    # HTTP management UI
    - '15672:15672'

Jag har här specificerat tre docker containers; Redis, Redis-commander samt RabbitMQ (med management). Dessa har jag hittat på https://hub.docker.com/search?q=&type=image. Där kan du även välja bland över 3 miljoner andra containrar, vilka möjligheter va? Under varje container har jag angivit en minimal konfiguration. En beskrivning om hur man konfigurerar respektive container finns oftast på hub.docker.com. Det man kan ta med sig från ovanstående konfigurering är vilka portar som öppnas. Här använder jag syntaxen HOST:CONTAINER, till exempel 8081:8081. Den vänstra sidan är alltså HOST, dvs din lokala maskin. Om den bakomliggande containern pratar via http så kan man surfa till http://localhost:8081 (eller vilken port som nu är angiven).

Konfigureringen säger att du kommer ha en Redisinstans körandes på localhost:6379, en redis commander på localhost:8081, en rabbitmq på samt en RabbitMQ på localhost:5672 samt RabbitMQ management portal på localhost:15672. Detta är din och endast din lokala infrastruktur!

Starta din infrastruktur

Lägg yml-filen i en katalog på valfritt ställe och öppna en kommandotolk i katalogen. Kör kommandot “docker-compose up” (alternativt “docker-compose up -d” för detatched-läge). När kommandot exekveras laddas alla kontainrar ner och startas. När allt är klart så kan du styra om ditt system att gå mot dina lokala instanser av respektive komponent.

Slutord

Av erfarenhet tycker jag att det är väldigt skönt att ha min infrastruktur lokalt och att kunna starta och stänga ner de tjänster som behövs när jag utvecklar. Jag slipper beroenden till servrar och kan t.ex. jobba offline utan att min infrastruktur går ner – ovärderligt om man t.ex. jobbar på tåget. Detta i kombination med en bra release pipeline där sökvägar till dessa beroenden kan bytas ut mot de riktiga är riktigt kraftfullt.

Andreas Hagsten, Infozone