CI/CD-ketjun luominen ja työn automatisointi Dockerin avulla

Kirjoitin ensimmäiset verkkosivustoni 90-luvun lopulla. Silloin niiden saattaminen toimintakuntoon oli erittäin helppoa. Jossain jaetussa hosting-tilassa oli Apache-palvelin, johon voit kirjautua FTP:n kautta kirjoittamalla jotain vastaavaa ftp://ftp.example.com. Sitten sinun piti kirjoittaa nimesi ja salasanasi ja ladata tiedostot palvelimelle. Oli erilaisia ​​aikoja, kaikki oli silloin yksinkertaisempaa kuin nyt.

Sen jälkeen kuluneiden kahden vuosikymmenen aikana kaikki on muuttunut paljon. Verkkosivustot ovat monimutkaistuneet, ne on koottava ennen tuotantoon pääsemistä. Yhdestä palvelimesta tuli useita kuormituksen tasaajien takana olevia palvelimia, ja versionhallintajärjestelmien käytöstä tuli yleistä.

Henkilökohtaista projektiani varten minulla oli erityinen kokoonpano. Ja tiesin, että tarvitsen mahdollisuuden ottaa sivusto käyttöön tuotannossa tekemällä vain yhden toiminnon: kirjoittamalla koodia haaraan master GitHubissa. Lisäksi tiesin, että varmistaakseni pienen verkkosovellukseni toiminnan en halunnut hallita valtavaa Kubernetes-klusteria, käyttää Docker Swarm -tekniikkaa tai ylläpitää palvelimia, joissa on podeja, agentteja ja kaikenlaista muuta. monimutkaisuus. Saavuttaakseni tavoitteen tehdä työstä mahdollisimman helppoa, minun piti tutustua CI/CD:hen.

Jos sinulla on pieni projekti (tässä tapauksessa Node.js-projekti) ja haluat tietää, kuinka tämän projektin käyttöönotto automatisoidaan varmistaen samalla, että arkistoon tallennetut tiedot täsmäävät tuotannossa toimivan kanssa, minä luulet, että saatat olla kiinnostunut tästä artikkelista.

Edellytykset

Tämän artikkelin lukijalta odotetaan perustiedot komentoriviltä ja Bash-skriptien kirjoittamisesta. Lisäksi hän tarvitsee tilit Travis CI и Docker-napa.

tavoitteet

En sano, että tätä artikkelia voidaan ehdottomasti kutsua "opetusohjelmaksi". Tämä on enemmänkin dokumentti, jossa kerron oppimistani ja kuvailen minulle sopivaa prosessia testaamiseen ja koodin käyttöönottoon tuotantoon yhdellä automaattisella läpikäynnillä.

Tähän minun työni päättyi.

Koodille, joka on lähetetty mihin tahansa arkiston haaraan paitsi master, suoritetaan seuraavat toiminnot:

• Projektin rakentaminen Travis CI:lle alkaa.
• Kaikki yksikkö-, integraatio- ja päästä päähän -testit suoritetaan.

Vain koodille, joka osuu master, suoritetaan seuraava:

• Kaikki edellä mainittu, plus...
• Docker-kuvan rakentaminen nykyisen koodin, asetusten ja ympäristön perusteella.
• Kuvan isännöinti Docker Hubissa.
• Yhteys tuotantopalvelimeen.
• Kuvan lataaminen Docker Hubista palvelimelle.
• Pysäytetään nykyinen säilö ja aloitetaan uusi uuden kuvan perusteella.

Jos et tiedä Dockerista, kuvista ja konteista mitään, älä huoli. Kerron sinulle siitä kaiken.

Mikä on CI/CD?

Lyhenne CI/CD tarkoittaa "jatkuvaa integrointia/jatkuvaa käyttöönottoa".

▍Jatkuva integrointi

Jatkuva integrointi on prosessi, jossa kehittäjät tekevät sitoumuksia projektin päälähdekoodivarastoon (yleensä haaraan master). Samalla koodin laatu varmistetaan automaattisella testauksella.

▍Jatkuva käyttöönotto

Jatkuva käyttöönotto on koodin toistuvaa, automaattista käyttöönottoa tuotantoon. CI/CD-lyhenteen toinen osa on joskus kirjoitettu "jatkuvaksi toimitukseksi". Tämä on periaatteessa sama kuin "jatkuva käyttöönotto", mutta "jatkuva toimitus" tarkoittaa, että muutokset on vahvistettava manuaalisesti ennen projektin käyttöönottoprosessin aloittamista.

Aloittaminen

Sovellus, jolla opin tämän kaiken, on nimeltään Pistä muistiin. Tämä on verkkoprojekti, jonka parissa työskentelen ja joka on suunniteltu muistiinpanojen tekemiseen. Ensin yritin tehdä JAMSstack-projekti tai pelkkä käyttöliittymäsovellus ilman palvelinta, jotta voit hyödyntää sen tarjoamia vakiohosting- ja projektinkäyttöominaisuuksia netlify. Sovelluksen monimutkaisuuden kasvaessa jouduin luomaan sen palvelinosan, mikä tarkoitti sitä, että minun piti muotoilla oma strategiani automatisoitua integrointia ja projektin automaattista käyttöönottoa varten.

Minun tapauksessani sovellus on Node.js-ympäristössä toimiva Express-palvelin, joka palvelee yksisivuista React-sovellusta ja tukee suojattua palvelinpuolen API:ta. Tämä arkkitehtuuri noudattaa strategiaa, joka löytyy tämä Täyspinon todennusopas.

neuvottelin kanssa muut, joka on automaatioasiantuntija, ja kysyi häneltä, mitä minun piti tehdä, jotta kaikki toimisi haluamallani tavalla. Hän antoi minulle idean siitä, miltä automatisoidun työnkulun pitäisi näyttää, ja se on kuvattu tämän artikkelin Tavoitteet-osiossa. Näiden tavoitteiden saavuttaminen tarkoitti, että minun piti selvittää, kuinka käyttää Dockeria.

Satamatyöläinen

Docker on työkalu, joka konttiteknologian ansiosta mahdollistaa sovellusten helpon jakamisen, käyttöönoton ja ajamisen samassa ympäristössä, vaikka itse Docker-alusta toimisi eri ympäristöissä. Ensin minun piti saada käsiini Dockerin komentorivityökalut (CLI). ohje Dockerin asennusopas ei ole kovin selkeä, mutta voit oppia siitä, että jotta voit ottaa asennuksen ensimmäisen vaiheen, sinun on ladattava Docker Desktop (Macille tai Windowsille).

Docker Hub on suunnilleen sama kuin GitHub git-tietovarastoille tai rekisterille NPM JavaScript-paketteja varten. Tämä on Docker-kuvien online-arkisto. Tähän Docker Desktop muodostaa yhteyden.

Joten, jotta voit aloittaa Dockerin käytön, sinun on tehtävä kaksi asiaa:

• Asettaa Telakkatyöpöytä.
• Rekisteröidy Docker-napa.

Tämän jälkeen voit tarkistaa, toimiiko Docker CLI, suorittamalla seuraava komento tarkistaaksesi Docker-version:

docker -v

Kirjaudu seuraavaksi Docker Hubiin antamalla käyttäjätunnuksesi ja salasanasi pyydettäessä:

docker login

Jotta voit käyttää Dockeria, sinun on ymmärrettävä kuvien ja säilöjen käsitteet.

▍Kuvat

Kuva on jotain suunnitelmaa, joka sisältää ohjeet säiliön kokoamiseen. Tämä on muuttumaton tilannekuva sovelluksen tiedostojärjestelmästä ja asetuksista. Kehittäjät voivat helposti jakaa kuvia.

# Вывод сведений обо всех образах
docker images

Tämä komento tulostaa taulukon, jossa on seuraava otsikko:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Seuraavaksi tarkastellaan joitain esimerkkejä samassa muodossa olevista komennoista - ensin on komento, jossa on kommentti, ja sitten esimerkki siitä, mitä se voi tuottaa.

▍ Säiliöt

Säiliö on suoritettava paketti, joka sisältää kaiken sovelluksen suorittamiseen tarvittavan. Tätä lähestymistapaa käyttävä sovellus toimii aina samalla tavalla infrastruktuurista riippumatta: eristetyssä ympäristössä ja samassa ympäristössä. Pointti on, että saman kuvan esiintymät käynnistetään eri ympäristöissä.

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍ Tunnisteet

Tunniste on osoitus kuvan tietystä versiosta.

▍Pikaopas Docker-komentoihin

Tässä on yleiskatsaus joihinkin yleisesti käytettyihin Docker-komentoihin.

Joukkue

konteksti

Действие

telakkarakennelma

kuva

Kuvan rakentaminen Docker-tiedostosta

telakkatunniste

kuva

Kuvan merkitseminen

docker -kuvia

kuva

Kuvien luettelointi

telakointi

Astia

Säilön suorittaminen kuvan perusteella

telakoitsijan työntö

kuva

Kuvan lataaminen rekisteriin

telakkaveto

kuva

Kuvan lataaminen rekisteristä

docker ps

Astia

Säiliöiden luettelointi

Docker-järjestelmän luumu

Kuva/säilö

Käyttämättömien säiliöiden ja kuvien poistaminen

▍ Docker-tiedosto

Tiedän kuinka tuotantosovellusta käytetään paikallisesti. Minulla on verkkopaketin konfiguraatio valmiin React-sovelluksen rakentamiseksi. Seuraavaksi minulla on komento, joka käynnistää Node.js-pohjaisen palvelimen portista 5000. Se näyttää tältä:

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

On huomattava, että minulla ei ole esimerkkisovellusta tälle materiaalille. Mutta tässä kokeissa mikä tahansa yksinkertainen solmusovellus käy.

Säiliön käyttöä varten sinun on annettava ohjeet Dockerille. Tämä tehdään tiedoston kautta Dockerfile, joka sijaitsee projektin juurihakemistossa. Tämä tiedosto vaikuttaa aluksi melko käsittämättömältä.

Mutta se, mitä se sisältää, kuvaa vain erikoiskomennoilla jotain samanlaista kuin työympäristön luominen. Tässä on joitain näistä komennoista:

• FROM — Tämä komento käynnistää tiedoston. Se määrittää peruskuvan, jolle säiliö on rakennettu.
• COPY — Tiedostojen kopioiminen paikallisesta lähteestä säilöön.
• TYÖOHJ — Työhakemiston asettaminen seuraaville komentoille.
• JUOSTA - Suorita komennot.
• ALTISTUMINEN — Porttiasetukset.
• SISÄÄNTULOPISTE — Ilmoitus suoritettavasta komennosta.

Dockerfile saattaa näyttää jotain tältä:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

Valitsemastasi peruskuvasta riippuen saatat joutua asentamaan lisäriippuvuuksia. Tosiasia on, että jotkut peruskuvat (kuten Node Alpine Linux) luodaan tavoitteena tehdä niistä mahdollisimman kompakteja. Tämän seurauksena heillä ei ehkä ole kaikkia odottamiasi ohjelmia.

▍Säilön rakentaminen, merkitseminen ja käyttäminen

Paikallinen kokoonpano ja kontin lanseeraus on vasta meillä Dockerfile, tehtävät ovat melko yksinkertaisia. Ennen kuin siirrät kuvan Docker Hubiin, sinun on testattava se paikallisesti.

▍ Kokoaminen

Ensin sinun on kerättävä kuva, joka määrittää nimen ja valinnaisesti tunnisteen (jos tunnistetta ei ole määritetty, järjestelmä määrittää kuvalle tunnisteen automaattisesti latest).

# Сборка образа
docker build -t <image>:<tag> .

Tämän komennon suorittamisen jälkeen voit katsella Dockerin rakentavan kuvan.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

Rakentaminen voi kestää muutaman minuutin - kaikki riippuu siitä, kuinka monta riippuvuutta sinulla on. Kun rakennus on valmis, voit suorittaa komennon docker images ja katso uuden kuvasi kuvaus.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍Käynnistä

Kuva on luotu. Tämä tarkoittaa, että voit käyttää säilöä sen perusteella. Koska haluan päästä käsiksi säiliössä olevaan sovellukseen osoitteessa localhost:5000, minä, parin vasemmalla puolella 5000:5000 seuraavassa komennossa asennettuna 5000. Oikealla puolella on konttiportti.

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

Nyt kun säilö on luotu ja käynnissä, voit käyttää komentoa docker ps tarkastellaksesi tämän säilön tietoja (tai voit käyttää komentoa docker ps -a, joka näyttää tiedot kaikista säilöistä, ei vain käynnissä olevista).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

Jos menet nyt osoitteeseen localhost:5000 — näet käynnissä olevan sovelluksen sivun, joka näyttää täsmälleen samalta kuin tuotantoympäristössä käynnissä olevan sovelluksen sivu.

▍ Tunnisteet ja julkaisu

Jotta voisimme käyttää yhtä luoduista kuvista tuotantopalvelimella, meidän on voitava ladata tämä kuva Docker Hubista. Tämä tarkoittaa, että sinun on ensin luotava arkisto projektille Docker Hubissa. Tämän jälkeen meillä on paikka, johon voimme lähettää kuvan. Kuva on nimettävä uudelleen niin, että sen nimi alkaa Docker Hub -käyttäjänimellämme. Tämän jälkeen tulisi kirjoittaa arkiston nimi. Mikä tahansa tunniste voidaan sijoittaa nimen loppuun. Alla on esimerkki kuvien nimeämisestä tätä mallia käyttäen.

Nyt voit rakentaa kuvan uudella nimellä ja suorittaa komennon docker push siirtääksesi sen Docker Hub -tietovarastoon.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

Jos kaikki menee hyvin, kuva on saatavilla Docker Hubissa ja se voidaan helposti ladata palvelimelle tai siirtää muille kehittäjille.

РЎР »РµРґСѓСЋС ‰ РёРµ С € Р ° РіРё

Tähän mennessä olemme varmistaneet, että Docker-säilön muodossa oleva sovellus toimii paikallisesti. Olemme ladaneet säilön Docker Hubiin. Kaikki tämä tarkoittaa, että olemme jo edistyneet erittäin hyvin kohti tavoitettamme. Nyt meidän on ratkaistava vielä kaksi kysymystä:

• CI-työkalun määrittäminen koodin testaamista ja käyttöönottoa varten.
• Tuotantopalvelimen asettaminen niin, että se voi ladata ja suorittaa koodimme.

Meidän tapauksessamme käytämme Travis CI. Palvelijana - DigitalOcean.

On huomattava, että täällä voit käyttää toista palveluyhdistelmää. Esimerkiksi Travis CI:n sijasta voit käyttää CircleCI- tai Github Actionsia. Ja DigitalOceanin sijaan - AWS tai Linode.

Päätimme työskennellä Travis CI:n kanssa, ja minulla on jo jotain määritetty tähän palveluun. Siksi puhun nyt lyhyesti siitä, kuinka se valmistetaan työhön.

Travis CI

Travis CI on työkalu koodin testaamiseen ja käyttöönottoon. En haluaisi mennä Travis CI:n perustamisen monimutkaisuuteen, koska jokainen projekti on ainutlaatuinen, eikä siitä ole paljon hyötyä. Mutta käsittelen perusasiat, jotta pääset alkuun, jos päätät käyttää Travis CI:tä. Valitsetpa Travis CI:n, CircleCI:n, Jenkinsin tai jonkin muun, samanlaisia ​​määritysmenetelmiä käytetään kaikkialla.

Aloita Travis CI:n käyttö siirtymällä osoitteeseen projektin verkkosivuilla ja luo tili. Integroi sitten Travis CI GitHub-tiliisi. Kun määrität järjestelmää, sinun on määritettävä arkisto, jonka kanssa haluat automatisoida työn ja sallia pääsy siihen. (Käytän GitHubia, mutta olen varma, että Travis CI voi integroida BitBucketin, GitLabin ja muiden vastaavien palvelujen kanssa).

Joka kerta, kun Travis CI käynnistetään, palvelin käynnistetään ja suorittaa määritystiedostossa määritetyt komennot, mukaan lukien vastaavien arkistohaarojen käyttöönotto.

▍Työn elinkaari

Travis CI -määritystiedosto nimeltään .travis.yml ja tallennettu projektin juurihakemistoon, tukee tapahtumien käsitettä elinkaari tehtäviä. Nämä tapahtumat on lueteltu siinä järjestyksessä, jossa ne tapahtuvat:

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍ Testaus

Aion määrittää paikallisen Travis CI -palvelimen asetustiedostossa. Valitsin kieleksi Node 12:n ja käskin järjestelmää asentaa Dockerin käytön edellyttämät riippuvuudet.

Kaikki mitä on listattu .travis.yml, suoritetaan, kun kaikki vetopyynnöt tehdään arkiston kaikkiin haaroihin, ellei toisin mainita. Tämä on hyödyllinen ominaisuus, koska se tarkoittaa, että voimme testata kaiken arkistoon tulevan koodin. Tämä kertoo, onko koodi valmis kirjoitettavaksi haaraan. master, ja rikkooko se projektin rakennusprosessia. Tässä globaalissa kokoonpanossa asensen kaiken paikallisesti, suoritan Webpack-dev-palvelinta taustalla (tämä on työnkulkuni ominaisuus) ja suoritan testejä.

Jos haluat arkistosi näyttävän merkkejä, jotka osoittavat testin kattavuuden, täällä Löydät lyhyet ohjeet Jestin, Travis CI:n ja haalareiden käyttämisestä näiden tietojen keräämiseen ja näyttämiseen.

Joten tässä on tiedoston sisältö .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

Tähän loppuvat toiminnot, jotka suoritetaan kaikille arkiston haareille ja vetopyynnöille.

▍Käyttöönotto

Olettaen, että kaikki automaattiset testit on suoritettu onnistuneesti, voimme, mikä on valinnaista, ottaa koodin käyttöön tuotantopalvelimelle. Koska haluamme tehdä tämän vain haaran koodille master, annamme järjestelmälle asianmukaiset ohjeet käyttöönottoasetuksissa. Ennen kuin yrität käyttää koodia, jota tarkastelemme seuraavaksi projektissasi, haluan varoittaa sinua siitä, että sinulla on oltava todellinen komentosarja, jota kutsutaan käyttöön.

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Käyttöönottokomentosarja ratkaisee kaksi ongelmaa:

• Rakenna, merkitse ja lähetä kuva Docker Hubiin käyttämällä CI-työkalua (tässä tapauksessa Travis CI).
• Kuvan lataaminen palvelimelle, vanhan kontin pysäyttäminen ja uuden käynnistäminen (tapauksessamme palvelin toimii DigitalOcean-alustalla).

Ensin sinun on määritettävä automaattinen prosessi kuvan rakentamiseksi, merkitsemiseksi ja työntämiseksi Docker Hubiin. Tämä kaikki on hyvin samanlaista kuin mitä olemme jo tehneet manuaalisesti, paitsi että tarvitsemme strategian yksilöllisten tunnisteiden määrittämiseksi kuville ja kirjautumisten automatisoimiseksi. Minulla oli vaikeuksia joidenkin käyttöönottoskriptin yksityiskohtien kanssa, kuten merkintästrategia, kirjautuminen, SSH-avaimen koodaus, SSH-yhteyden muodostaminen. Mutta onneksi poikaystäväni on erittäin hyvä bashin kanssa, kuten monissa muissakin asioissa. Hän auttoi minua kirjoittamaan tämän käsikirjoituksen.

Joten, skriptin ensimmäinen osa on kuvan lataaminen Docker Hubiin. Tämä on melko helppo tehdä. Käyttämäni merkintäjärjestelmä sisältää git-hash- ja git-tagin yhdistämisen, jos sellainen on olemassa. Tämä varmistaa, että tunniste on ainutlaatuinen ja helpottaa sen kokoonpanon tunnistamista, johon se perustuu. DOCKER_USERNAME и DOCKER_PASSWORD ovat käyttäjäympäristömuuttujia, jotka voidaan asettaa käyttämällä Travis CI -liitäntää. Travis CI käsittelee arkaluontoisia tietoja automaattisesti, jotta ne eivät joudu vääriin käsiin.

Tässä on käsikirjoituksen ensimmäinen osa deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

Se, mikä skriptin toinen osa on, riippuu täysin käyttämästäsi isännästä ja siitä, kuinka yhteys siihen on järjestetty. Minun tapauksessani, koska käytän Digital Oceania, käytän komentoja yhteyden muodostamiseen palvelimeen docl. Kun työskentelet AWS:n kanssa, apuohjelmaa käytetään aws, ja niin edelleen.

Palvelimen asentaminen ei ollut erityisen vaikeaa. Joten asensin pisaran peruskuvan perusteella. On huomattava, että valitsemani järjestelmä vaatii Dockerin kertaluonteisen manuaalisen asennuksen ja Dockerin manuaalisen kertakäynnistyksen. Asensin Dockerin Ubuntu 18.04:llä, joten jos käytät myös Ubuntua samaan, voit seurata tämä yksinkertainen ohje.

En puhu tässä palvelun erityisistä komennoista, koska tämä näkökohta voi vaihdella suuresti eri tapauksissa. Annan vain yleisen toimintasuunnitelman, joka suoritetaan sen jälkeen, kun olen muodostanut yhteyden SSH:n kautta palvelimeen, johon projekti otetaan käyttöön:

• Meidän on löydettävä tällä hetkellä käynnissä oleva kontti ja pysäytettävä se.
• Sitten sinun on käynnistettävä uusi säilö taustalla.
• Sinun on asetettava palvelimen paikallinen portti 80 - Tämän avulla voit kirjoittaa sivuston osoitteeseen, kuten example.com, määrittelemättä porttia sen sijaan, että käytät osoitetta, kuten example.com:5000.
• Lopuksi sinun on poistettava kaikki vanhat säilöt ja kuvat.

Tässä on jatkoa käsikirjoitukselle.

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

Joitakin asioita, joihin kannattaa kiinnittää huomiota

On mahdollista, että kun muodostat yhteyden palvelimeen SSH:n kautta Travis CI:stä, näet varoituksen, joka ei anna sinun jatkaa asennusta, koska järjestelmä odottaa käyttäjän vastausta.

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

Opin, että merkkijonoavain voidaan koodata base64:ään, jotta se voidaan tallentaa sellaiseen muotoon, jossa sitä voidaan käsitellä kätevästi ja luotettavasti. Asennusvaiheessa voit purkaa julkisen avaimen ja kirjoittaa sen tiedostoon known_hosts päästäksesi eroon yllä olevasta virheestä.

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

Käytännössä tämä komento voi näyttää tältä:

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

Ja tässä on mitä se antaa - base64-koodattu merkkijono:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Tässä on yllä mainittu komento

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

Samaa lähestymistapaa voidaan käyttää yksityisen avaimen kanssa yhteyttä muodostettaessa, koska saatat tarvita yksityisen avaimen päästäksesi palvelimeen. Kun työskentelet avaimen kanssa, sinun on vain varmistettava, että se on tallennettu turvallisesti Travis CI -ympäristömuuttujaan ja ettei sitä näytetä missään.

Toinen huomioitava asia on, että saatat joutua suorittamaan koko käyttöönottokomentosarjan yhtenä rivinä, esimerkiksi - kanssa doctl. Tämä saattaa vaatia lisäponnistuksia.

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL ja kuormituksen tasapainotus

Kun tein kaiken yllä mainitun, viimeinen kohtaamani ongelma oli se, että palvelimella ei ollut SSL:ää. Koska käytän Node.js-palvelinta, pakottaakseni töihin käänteinen välityspalvelin Nginx ja Let's Encrypt, sinun täytyy puuhailla paljon.

En todellakaan halunnut tehdä kaikkea tätä SSL-määritystä manuaalisesti, joten loin vain kuormituksen tasapainottimen ja tallensin sen tiedot DNS:ään. Esimerkiksi DigitalOceanin tapauksessa automaattisesti uusiutuvan itseallekirjoitetun varmenteen luominen kuormituksen tasapainottimeen on yksinkertainen, ilmainen ja nopea toimenpide. Tällä lähestymistavalla on lisäetuna, että sen avulla on erittäin helppoa määrittää SSL useille palvelimille, jotka toimivat kuormituksen tasapainottimen takana tarvittaessa. Näin palvelimet eivät itse voi "ajatella" SSL:ää ollenkaan, vaan käyttää porttia tavalliseen tapaan 80. Joten SSL:n määrittäminen kuormituksen tasapainottimessa on paljon helpompaa ja kätevämpää kuin vaihtoehtoiset SSL-määritystavat.

Nyt voit sulkea kaikki palvelimen portit, jotka hyväksyvät saapuvat yhteydet - porttia lukuun ottamatta 80, jota käytetään kommunikoimaan kuormantasaajan ja portin kanssa 22 SSH:lle. Tämän seurauksena yritys päästä suoraan palvelimeen muista porteista kuin näistä kahdesta portista epäonnistuu.

Tulokset

Kun tein kaiken, mistä tässä materiaalissa puhuin, Docker-alusta tai automatisoitujen CI/CD-ketjujen käsitteet eivät enää pelänneet minua. Pystyin luomaan jatkuvan integraatioketjun, jonka aikana koodi testataan ennen tuotantoon menoa ja koodi otetaan automaattisesti käyttöön palvelimella. Tämä kaikki on minulle vielä suhteellisen uutta, ja olen varma, että on olemassa tapoja parantaa automatisoitua työnkulkuani ja tehdä siitä tehokkaampi. Joten jos sinulla on ideoita tähän asiaan, kerro minulle. minua tietää. Toivon, että tämä artikkeli on auttanut sinua pyrkimyksissäsi. Haluan uskoa, että sen lukemisen jälkeen opit yhtä paljon kuin minä opin samalla kun tajusin kaiken, mistä siinä puhuin.

PS. Meidän markkinapaikka on kuva Satamatyöläinen, joka voidaan asentaa yhdellä napsautuksella. Voit tarkistaa konttien toiminnan osoitteessa VPS. Kaikille uusille asiakkaille annetaan 3 päivää maksutonta testausta.

Hyvä lukijat! Käytätkö projekteissasi CI/CD-tekniikoita?

Lähde: will.com