Skapa ett Docker-kluster med hjälp av PowerShell

Innan alla går över till nya bättre Azure Resource Manager, tänkte jag dela med mig av ett PowerShell-script som deploy:ar tre noder baserat på senaste CoreOS alphan med etcd, fleet startat och Docker redo. Alla kommandon, script och config filer ligger på min GitHub och rättas kontinuerligt om fel hittas. VIKTIGT att du ändrar på namnen från "your" samt ändrar användare och lösenord. Direkt efter du skapat noderna bör du även skapa privata ssh nycklar och stänga ner inloggning med lösenord då det är betydligt säkrare.

Förutsättningar:

• Du har en befintlig Azure subscription
• Du kör från ett Windows OS, eller som jag Windows i Vmware fusion
• Du har installerat Powershell, jag rekommenderar Powershell ISE, då det är bra när man kör script
• Du har laddat in Azure modulen för powershell, använd gärna detta PS script för att hålla modulen uppdaterad

Börja med att starta PowerShell och logga in mot Azure antingen genom nedan kommando eller hämta och importera management certifikatet enligt denna guide.

Om du har flera subscriptions, välj det som du vill använda för ditt docker kluster. Verifiera att du valt rätt med att kolla vilka resurser som finns (om du har några).

Så nu har vi loggat in mot Azure samt valt rätt subscription. Då är det dags att börja konfigurera!

Om du har nätverkskonfig idag i Azure, ladda ner den och editera filen. Om du inte har några egna vnet så kommer Get-AzureVnetConfig kommandot gå igenom utan felmeddelande och inte ladda ner någon fil. Använd då min exempelfil och editera den och ladda upp genom Set-AzureVnetConfig direkt. Om du har konfiguration, lägg till min exempelkonfig men ändra enligt din namnstandard.

Vi hämtar nätconfigen.

Editera sedan vnetconfig.netcfg och lägg till nedan info om det nya nätet med subnät eller om du inte fick ner någon fil gå direkt till nästa steg och ladda upp konfig filen. OBS kolla noggrant att syntaxen är rätt då den skriver över din befintliga konfig.

När det är klart kan du ladda upp din editerade vnetconfig.netcfg

Nu ska du ha ett nytt virtual network, verifiera att du skapat det med:

Nu ska vi skapa ett unikt token för etcd som klustret använder för att kommunicera. Viktigt är att detta är unikt för varje installation, annars kommer klustret inte lira. Om du installerar om flera gånger eller har fler olika kluster är det därför viktigt att skapa ett nytt unikt varje gång.

Surfa in mot https://discovery.etcd.io/new och kopiera URL:en med ditt unika ID. Ta sedan det och ersätt strängen i cloud-config.yaml filen nedan. Cloud config är en konfigurationsfil för coreOS som används vid installationer för att sätta upp etcd, fleet samt tex hur man ska uppdatera coreOS.

Spara cloud-config.yaml och kom ihåg vilken path den ligger under. Nu ska vi editera vårt PowerShell script så det är rätt namnstandard och konton enligt din miljö. Gå igenom scriptet nedan och ändra alla "your" samt konto och password så det passar dig. Storleken på servrarna är "Small" vilket är i skrivande stund en A1 modell motsvarande 1CPU core, 1,75GB RAM och 70GB disk. Ändra efter behov och spara sedan filen.

Nu är vi redo att exekvera skriptet och installera! I ditt PowerShell-fönster kör scriptet eller om du använder PowerShell ISE, öppna filen och tryck på "Run Script (F5)". Du kan få lite varningar på georeplication och Vnetname när de virtuella servrarna skapas, men det är inget att oroa sig för.

När allt är klart och installerat tar det en kort stund för noderna att starta upp, medans du väntar kollar du upp vilka publika portar din noder använder för ssh. Kör kommandot för respektive server och kolla vilken port som används under SSH i högra kolumnen.

När noderna är uppe connecta med ssh mot youruser@yourcloud01.cloudapp.net med den publika ssh porten. Om du kör från linux eller mac så kör du med nedan kommando från terminalen, annars kan du köra putty från windows, glöm inte att ändra ssh portnummret som du fick ovan.

Väl inne på servern kan du köra journalctl för att kolla så cloud config gick igenom ok

Outputen borde likna nedan, inga errors och avslutas med "Started Cloudinit from Azure metadata."

-- Logs begin at Wed 2015-06-17 10:00:11 UTC, end at Wed 2015-06-17 11:54:07 UTC. --
Jun 17 10:00:39 localhost systemd[1]: Starting Cloudinit from Azure metadata...
Jun 17 10:00:39 localhost coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:39 localhost coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:40 localhost coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:40 localhost coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:41 localhost coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:42 localhost coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:46 yournode01 coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: Checking availability of "waagent"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: Fetching user-data from datasource of type "waagent"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: Attempting to read from "/var/lib/waagent/CustomData"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: Fetching meta-data from datasource of type "waagent"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: Attempting to read from "/var/lib/waagent/SharedConfig.xml"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Parsing user-data as cloud-config
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: Merging cloud-config from meta-data and user-data
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Writing file to "/etc/coreos/update.conf"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Wrote file to "/etc/coreos/update.conf"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Wrote file /etc/coreos/update.conf to filesystem
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Writing file to "/etc/environment"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Wrote file to "/etc/environment"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Updated /etc/environment
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Writing drop-in unit "20-cloudinit.conf" to filesystem
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Writing file to "/run/systemd/system/etcd.service.d/20-cloudinit.conf"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Wrote file to "/run/systemd/system/etcd.service.d/20-cloudinit.conf"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Wrote drop-in unit "20-cloudinit.conf"
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Ensuring runtime unit file "etcd.service" is unmasked
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Ensuring runtime unit file "etcd2.service" is unmasked
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Ensuring runtime unit file "fleet.service" is unmasked
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Ensuring runtime unit file "locksmithd.service" is unmasked
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Ensuring runtime unit file "locksmithd.service" is unmasked
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Calling unit command "start" on "etcd.service"'
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Result of "start" on "etcd.service": done
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Calling unit command "start" on "fleet.service"'
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Result of "start" on "fleet.service": done
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Calling unit command "restart" on "locksmithd.service"'
Jun 17 10:00:52 yournode01 coreos-cloudinit[562]: 2015/06/17 10:00:52 Result of "restart" on "locksmithd.service": done
Jun 17 10:00:52 yournode01 systemd[1]: Started Cloudinit from Azure metadata.

Kolla sedan så att fleet är igång och alla noder har joinat klustret.

Outputen borde likna denna:

MACHINE IP METADATA
32335bb1... 10.0.1.6 -
8ca94c86... 10.0.1.5 -
915fce7c... 10.0.1.7 -

Nu har vi ett kluster bestående av tre coreOS virtuella servrar med etcd samt fleet startat och docker redo. Noderna är i en cloudgrupp så man kan addressera noderna med ett publikt IP. För att göra ett enkelt test av docker så kör nedan kommando. Den hämtar centOS från docker biblioteket, installerar och exekverar "hello world".

För att skapa en varaktig docker med din applikation, tex en LAMP stack så finns det bra guider hos coreOS, där finns det även bra info om fleet och systemd.

‍Glöm inte att skapa privata ssh nycklar och stänga ner inloggning med lösenord då det är betydligt säkrare.

‍Vill du rensa hela din miljö så kan du använda följande script, ibland så får man köra den flera gånger då Azure låser upp diskarna mot de virtuella servrarna och tar ett tag innan dom släpps tillbaka för "radering".

OBS, virtuella nätverket är kvar, ta bort det genom webportalen alternativ ladda upp en "tom" vnetconfig men BARA om du inte har andra virtuella nätverk sen tidigare.

Hoppas den här guiden gav en inblick om hur man deployar genom powershell, lämna gärna kommentarer eller hör av dig efter du provat!