Docker Compose vs Docker Swarm

Konteineri „revolutsiooni” rakendused on kasvanud palju enamaks kui lihtsalt andmebaasiks ja kasutajaliideseks. Rakendused on jagatud erinevateks mikroteenusteks ja tavaliselt suhtlevad nad omavahel REST API kaudu (tavaliselt JSON -vormingus kasulikud koormused HTTP kaudu). Dockeri konteinerid sobivad ideaalselt sellise arhitektuuri jaoks. Saate oma kasutajaliidese mikroteenuse pakendada Dockeri konteinerisse, andmebaas läheb teise ja nii edasi ja nii edasi. Iga teenus räägib teisega eelnevalt määratletud REST API kaudu, selle asemel et olla monoliit, mis on kirjutatud ühe tarkvaratükina.

Kui teil on vaja rakendada uut funktsiooni või funktsiooni, nt analüüsimootorit, saate selle jaoks lihtsalt uue mikroteenuse kirjutada ja see kulutaks andmeid teie veebirakenduse erinevate mikroteenuste poolt eksponeeritud REST API kaudu. Ja kui teie funktsionaalsus aja jooksul kasvab, suureneb koos sellega ka mikroteenuste loend.

Te ei soovi iga konteinerit juurutada, seadistada see ja seejärel konfigureerida kõik muu, et ka temaga rääkida. Isegi kolme konteineriga läheb see tüütuks. Docker-Compose võimaldab automatiseerida mitme konteineri juurutamist.

Docker-Compose on üks lihtsamaid tööriistu, mis aitab teil muuta mikroteenuste abstraktse idee funktsionaalseks Dockeri konteineri komplektiks.

Hajutatud süsteemid

Nüüd, kui oleme veebirakenduse mitmeks konteineriks lahti jaganud, pole mõtet hoida neid kõiki ühes serveris (veel hullem ühes virtuaalmasinas!), Kus hakkavad mängima sellised teenused nagu Docker Swarm ja Kubernetes.

Docker Swarm võimaldab teil käivitada oma rakenduse mitu koopiat mitmes serveris. Kui teie mikroteenus on kirjutatud nii, et seda saab horisontaalselt skaleerida, saate Docker Swarmi abil oma veebirakenduse juurutada mitmetes andmekeskustes ja mitmes piirkonnas. See pakub vastupidavust ühe või mitme andmekeskuse või võrgulingi tõrke vastu. Seda tehakse tavaliselt Dockeri alamkäskluse, st Docker Stacki abil.

The Docker Stack alamkäsklus käitub palju rohkem nagu käsk Docker-Compose ja see võib kumbki tehnoloogiat kasutavale inimesele tekitada väärarusaamu.

Segaduse allikas

Kasutamise ja töövoo osas töötavad mõlemad tehnoloogiad üksteisega väga sarnaselt ja see tekitab segadust. Rakenduse Docker Swarm või Docker-Compose abil juurutamise viis on väga sarnane. Teie määratlete oma rakenduse YAML -failis, see fail sisaldab pildi nime, iga pildi konfiguratsiooni ja ka skaalat (koopiate arv), millega iga mikroteenus juurutamisel nõutakse.

Erinevus seisneb enamasti taustal, kus docker-compose paigutab konteineri ühele Dockeri hostile, Docker Swarm juurutab selle mitme sõlme vahel. Vabalt öeldes saab see siiski teha enamikku asju, mida docker-compose suudab, kuid skaleerib seda mitme Dockeri hosti vahel.

Sarnasused

Nii Docker Swarmil kui ka Docker-Compose'il on järgmised sarnasused:

1. Mõlemad kasutavad teie rakenduste virna YAML -vormingus määratlusi.
2. Mõlemad on mõeldud mitme konteineri rakendustega (mikroteenused)
3. Mõlemal on skaala parameeter, mis võimaldab teil käivitada sama pildi mitu konteinerit, võimaldades teie mikroteenusel horisontaalselt skaleerida.
4. Neid hooldab sama ettevõte, st Docker, Inc.

Erinevused

Mõned erinevused Docker Swarmi ja Docker-Compose vahel:

1. Docker Swarmit kasutatakse teie veebirakenduse skaleerimiseks ühe või mitme serveri vahel. Kus Docker-compose käivitab teie veebirakenduse lihtsalt ühes Dockeri hostis.
2. Veebirakenduse skaleerimine Docker Swarm pakub tõsist kättesaadavust ja tõrketaluvust. Veebirakenduse skaleerimine Docker-Compose abil ühele hostile on kasulik ainult testimiseks ja arendamiseks.
3. Docker Swarm ja sellega seotud alamkäsklused, nagu Docker Swarm ja Docker Stack, on sisse ehitatud Docker CLI -sse. Need kõik on osa Dockeri binaarist, millele helistate oma terminali kaudu. Docker-Compose on iseenesest iseseisev binaarne.

Kasutusjuht Docker-Compose jaoks

Nagu eespool kirjeldatud, on need mõlemad täiesti erinevad tööriistad ja mõlemad lahendavad täiesti erineva probleemi, nii et pole nii, et üks oleks teisele alternatiiv. Kuid selleks, et anda uutele tulijatele aimu, millest ma räägin, on siin Docker Compose'i kasutusjuhend.

Oletame, et soovite ise hostida WordPressi ajaveebi ühes serveris. Selle seadistamine või hooldamine pole midagi, mida soovite käsitsi teha, nii et selle asemel peaksite installima oma VPS-i Dockeri ja Docker-compose'i, looma lihtsa YAML-faili, mis määratleb teie WordPressi virna kõik aspektid, nagu allpool, :

Märkus. Kui kasutate WordPressi saidi juurutamiseks järgmist, muutke kõik paroolid turvaliseks. Veelgi parem, kasutage Dockeri saladusi, et salvestada tundlikke andmeid, näiteks paroole, selle asemel, et neid tavalises tekstifailis hoida.

Kui fail on loodud ja nii Docker kui ka Docker-compose on installitud, peate vaid käivitama:

Ja teie sait käivitatakse. Kui värskendus on saadaval, käivitage see:

Seejärel visake Dockeri vanad pildid minema ja käivitage käsk docker -compose up -d ning uued pildid tõmmatakse automaatselt sisse. Kuna teie püsivad andmed on salvestatud Dockeri köites, ei kao teie veebisaidi sisu.

Millal Docker Swarm'i kasutada?

Kui Docker-compose on pigem automatiseerimistööriist, siis Docker Swarm on mõeldud nõudlikumate rakenduste jaoks. Veebirakendused, millel on sadu või tuhandeid kasutajaid või töökoormus, mida tuleb paralleelselt skaleerida. Ettevõtted, kellel on suur kasutajaskond ja ranged SLA nõuded, sooviksid kasutada hajusüsteemi nagu Docker Swarm. Kui teie rakendus töötab mitmes serveris ja mitmes andmekeskuses, väheneb mõjutatud alalisvoolu- või võrgulingi tõttu seisakute tõenäosus oluliselt.

Sellegipoolest soovitan kõhklematult Docker Swarmit tootmiseks kasutada, sest konkureerivad tehnoloogiad, nagu Kubernetes, on selle ülesande jaoks vaieldamatult sobivamad. Kubernetesi toetavad paljud pilveteenuse pakkujad ja see töötab Dockeri konteineritega üsna hästi, nii et te ei pea isegi oma rakendust Kubernetese kasutamiseks uuesti üles ehitama.

Järeldus

Loodan, et see raputamine Dockeris ja selle satelliitprojektides oli informatiivne ja olete doki ökosüsteemi jaoks rohkem valmis.