Crear unha cadea de CI/CD e automatizar o traballo con Docker

Escribín os meus primeiros sitios web a finais dos 90. Daquela era moi sinxelo poñelos en funcionamento. Había un servidor Apache nalgún hospedaxe compartido, podías iniciar sesión neste servidor a través de FTP escribindo algo así ftp://ftp.example.com. Despois tiñas que introducir o teu nome e contrasinal e cargar os ficheiros ao servidor. Había tempos diferentes, entón todo era máis sinxelo que agora.

Nas dúas décadas transcorridos dende entón, todo cambiou moito. Os sitios web volvéronse máis complexos; deben montarse antes de ser lanzados en produción. Un único servidor converteuse en moitos servidores que funcionan detrás dos equilibradores de carga, e o uso de sistemas de control de versións converteuse nun habitual.

Para o meu proxecto persoal tiña unha configuración especial. E sabía que necesitaba a capacidade de implementar o sitio en produción realizando só unha acción: escribir código nunha rama master en GitHub. Ademais, sabía que, para garantir o funcionamento da miña pequena aplicación web, non quería xestionar un enorme clúster de Kubernetes, nin utilizar a tecnoloxía Docker Swarm nin manter unha flota de servidores con pods, axentes e todo tipo de outros. complexidades. Para conseguir o obxectivo de facer o traballo o máis sinxelo posible, necesitaba familiarizarme co CI/CD.

Se tes un proxecto pequeno (neste caso, un proxecto Node.js) e queres saber como automatizar o despregamento deste proxecto, ao tempo que te aseguras de que o que se almacena no repositorio coincida exactamente co que funciona en produción, entón eu creo que pode estar interesado neste artigo.

Requisitos previos

Espérase que o lector deste artigo teña unha comprensión básica da liña de comandos e escriba scripts Bash. Ademais, necesitará contas Travis C.I. и Hub Docker.

Obxectivos

Non direi que este artigo pode chamarse incondicionalmente "titorial". Este é máis ben un documento no que falo do que aprendín e describo o proceso que me convén para probar e implementar código en produción, realizado nun paso automatizado.

Este é o que acabou sendo o meu fluxo de traballo.

Para o código publicado en calquera rama do repositorio excepto master, realízanse as seguintes accións:

• Comeza o proxecto construído sobre Travis CI.
• Realízanse todas as probas unitarias, de integración e de extremo a extremo.

Só para o código que cae master, realízase o seguinte:

• Todo o mencionado anteriormente, ademais...
• Construír unha imaxe de Docker baseada no código, a configuración e o ambiente actuais.
• Implementando a imaxe no Docker Hub.
• Conexión ao servidor de produción.
• Cargando unha imaxe desde Docker Hub ao servidor.
• Deter o contedor actual e iniciar un novo baseado na nova imaxe.

Se non sabes absolutamente nada sobre Docker, imaxes e contedores, non te preocupes. Vouche contar todo.

Que é CI/CD?

A abreviatura CI/CD significa "integración continua/despliegue continuo".

▍Integración continua

A integración continua é un proceso no que os desenvolvedores realizan compromisos co repositorio de código fonte principal do proxecto (normalmente unha rama master). Ao mesmo tempo, a calidade do código está garantida mediante probas automatizadas.

▍Impregamento continuo

O despregamento continuo é o despregamento frecuente e automatizado de código na produción. A segunda parte do acrónimo CI/CD ás veces se escribe como "entrega continua". Isto é basicamente o mesmo que a "implementación continua", pero a "entrega continua" implica a necesidade de confirmar manualmente os cambios antes de iniciar o proceso de implantación do proxecto.

introdución

A aplicación que usei para aprender todo isto chámase Toma nota. Este é un proxecto web no que estou a traballar, pensado para tomar notas. Ao principio tentei facelo JAMSstack-proxecto, ou só unha aplicación front-end sen servidor, para aproveitar as capacidades estándar de aloxamento e implantación de proxectos que ofrece netlify. A medida que creceu a complexidade da aplicación, necesitaba crear a súa parte de servidor, o que significaba que necesitaría formular a miña propia estratexia para a integración automatizada e a implantación automatizada do proxecto.

No meu caso, a aplicación é un servidor Express que se executa no contorno Node.js, que serve unha aplicación React dunha soa páxina e admite unha API segura do lado do servidor. Esta arquitectura segue a estratexia que se pode atopar en esta Guía de autenticación de pila completa.

Consultei con amigo, que é un experto en automatización, e preguntoulle que tiña que facer para que todo funcione como eu quería. Deume a idea de como debería ser un fluxo de traballo automatizado, descrito na sección Obxectivos deste artigo. Ter estes obxectivos significaba que necesitaba descubrir como usar Docker.

Estivador

Docker é unha ferramenta que, grazas á tecnoloxía de contenerización, permite que as aplicacións sexan facilmente distribuídas, despregadas e executadas nun mesmo entorno, aínda que a propia plataforma Docker se execute en diferentes contornas. En primeiro lugar, necesitaba ter as miñas mans nas ferramentas de liña de comandos (CLI) de Docker. Instrucións A guía de instalación de Docker non se pode chamar moi clara e comprensible, pero dela podes aprender que para dar o primeiro paso de instalación, cómpre descargar Docker Desktop (para Mac ou Windows).

Docker Hub é aproximadamente o mesmo que GitHub para repositorios git ou rexistro npm para paquetes JavaScript. Este é un repositorio en liña de imaxes de Docker. Isto é ao que se conecta Docker Desktop.

Polo tanto, para comezar con Docker, debes facer dúas cousas:

• Conxunto Escritorio Docker.
• Rexístrese en Hub Docker.

Despois diso, pode comprobar se a CLI de Docker funciona executando o seguinte comando para comprobar a versión de Docker:

docker -v

A continuación, inicie sesión en Docker Hub introducindo o seu nome de usuario e contrasinal cando se lle solicite:

docker login

Para usar Docker, debes comprender os conceptos de imaxes e contedores.

▍Imaxes

Unha imaxe é algo así como un plano que contén instrucións para montar o recipiente. Esta é unha instantánea inmutable do sistema de ficheiros e da configuración da aplicación. Os desenvolvedores poden compartir imaxes facilmente.

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

Este comando mostrará unha táboa coa seguinte cabeceira:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

A continuación veremos algúns exemplos de comandos no mesmo formato: primeiro hai un comando cun comentario e despois un exemplo do que pode emitir.

▍Contenedores

Un contedor é un paquete executable que contén todo o necesario para executar unha aplicación. Unha aplicación con este enfoque sempre funcionará igual, independentemente da infraestrutura: nun ambiente illado e no mesmo ambiente. A cuestión é que as instancias da mesma imaxe lánzanse en diferentes ambientes.

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

▍Etiquetas

Unha etiqueta é unha indicación dunha versión específica dunha imaxe.

▍Unha referencia rápida aos comandos de Docker

Aquí tes unha visión xeral dalgúns comandos de Docker de uso habitual.

Equipo

Contexto

efecto

compilación docker

Imaxe

Construír unha imaxe desde un Dockerfile

etiqueta docker

Imaxe

Etiquetado de imaxes

imaxes docker

Imaxe

Listado de imaxes

executar docker

Recipiente

Execución dun contedor baseado nunha imaxe

docker push

Imaxe

Cargando unha imaxe ao rexistro

docker pull

Imaxe

Cargando unha imaxe do rexistro

ps docker

Recipiente

Listado de contedores

poda do sistema docker

Imaxe/Contedor

Eliminación de envases e imaxes non utilizados

▍Dockerfile

Sei como executar unha aplicación de produción localmente. Teño unha configuración Webpack deseñada para construír unha aplicación React preparada. A continuación, teño un comando que inicia un servidor baseado en Node.js no porto 5000. Parece así:

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

Nótese que non teño un exemplo de aplicación para este material. Pero aquí, para experimentos, calquera aplicación simple de Node servirá.

Para usar o contedor, terás que darlle instrucións a Docker. Isto faise a través dun ficheiro chamado Dockerfile, situado no directorio raíz do proxecto. Este ficheiro, nun principio, parece bastante incomprensible.

Pero o que contén só describe, con comandos especiais, algo semellante a configurar un ambiente de traballo. Aquí están algúns destes comandos:

• DE — Este comando inicia un ficheiro. Especifica a imaxe base sobre a que está construído o contedor.
• COPY — Copiar ficheiros dunha fonte local a un contedor.
• DIR. TRABALLO — Establecer o directorio de traballo para os seguintes comandos.
• RUN - Executar comandos.
• EXPOÑER - Configuración do porto.
• PUNTO DE ENTRADA — Indicación do comando que se vai executar.

Dockerfile pode parecer algo así:

# Загрузить базовый образ
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

Dependendo da imaxe base que elixas, é posible que necesites instalar dependencias adicionais. O caso é que algunhas imaxes base (como Node Alpine Linux) créanse co obxectivo de facelas o máis compactas posible. Como resultado, é posible que non teñan algúns dos programas que esperas.

▍Construír, etiquetar e executar o contedor

A montaxe local e o lanzamento do contedor é despois de que teñamos Dockerfile, as tarefas son bastante sinxelas. Antes de enviar a imaxe a Docker Hub, cómpre probala localmente.

▍Asemblea

Primeiro cómpre recoller imaxe, especificando un nome e, opcionalmente, unha etiqueta (se non se especifica unha etiqueta, o sistema asignará automaticamente unha etiqueta á imaxe latest).

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

Despois de executar este comando, podes ver que Docker crea a imaxe.

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

A construción pode levar un par de minutos; todo depende de cantas dependencias teñas. Unha vez completada a compilación, pode executar o comando docker images e mira a descrición da túa nova imaxe.

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

▍Lanzamento

Creouse a imaxe. Isto significa que pode executar un contedor baseado nel. Porque quero poder acceder á aplicación que se executa no contedor en localhost:5000, eu, no lado esquerdo da parella 5000:5000 no seguinte comando instalado 5000. No lado dereito está o porto de contedores.

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

Agora que o contedor está creado e en execución, podes usar o comando docker ps para ver información sobre este contenedor (ou pode usar o comando docker ps -a, que mostra información sobre todos os contedores, non só sobre os que están en execución).

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

Se agora vai ao enderezo localhost:5000 — pode ver unha páxina dunha aplicación en execución que ten exactamente o mesmo aspecto que a páxina dunha aplicación que se executa nun ambiente de produción.

▍Etiquetado e publicación

Para poder usar unha das imaxes creadas no servidor de produción, necesitamos poder descargar esta imaxe desde Docker Hub. Isto significa que primeiro debes crear un repositorio para o proxecto en Docker Hub. Despois disto, teremos un lugar onde poderemos enviar a imaxe. Hai que renomear a imaxe para que o seu nome comece polo noso nome de usuario de Docker Hub. Este debe ir seguido do nome do repositorio. Calquera etiqueta pódese colocar ao final do nome. A continuación móstrase un exemplo de nomeamento de imaxes usando este esquema.

Agora podes construír a imaxe cun novo nome e executar o comando docker push para envialo ao repositorio de Docker Hub.

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

Se todo vai ben, a imaxe estará dispoñible en Docker Hub e poderá cargarse facilmente no servidor ou transferirse a outros desenvolvedores.

Próximos pasos

A estas alturas comprobamos que a aplicación, en forma de contedor Docker, está a executarse localmente. Cargamos o contedor en Docker Hub. Todo isto significa que xa avanzamos moi ben no noso obxectivo. Agora temos que resolver dúas preguntas máis:

• Configurar unha ferramenta de CI para probar e implementar código.
• Configurando o servidor de produción para que poida descargar e executar o noso código.

No noso caso, usamos Travis C.I.. Como servidor - DitigalOcean.

Nótese que aquí pode utilizar outra combinación de servizos. Por exemplo, en lugar de Travis CI, podes usar CircleCI ou Github Actions. E en lugar de DigitalOcean - AWS ou Linode.

Decidimos traballar con Travis CI, e xa teño algo configurado neste servizo. Polo tanto, agora falarei brevemente de como preparalo para o traballo.

Travis C.I.

Travis CI é unha ferramenta para probar e implementar código. Non me gustaría entrar nas complejidades de configurar Travis CI, xa que cada proxecto é único, e isto non traerá moito beneficio. Pero cubrirei os conceptos básicos para comezar se decides usar Travis CI. Se escolles Travis CI, CircleCI, Jenkins ou outra cousa, utilizaranse métodos de configuración similares en todas partes.

Para comezar con Travis CI, vai a sitio web do proxecto e crea unha conta. A continuación, integra Travis CI coa túa conta de GitHub. Ao configurar o sistema, terás que especificar o repositorio co que queres automatizar o traballo e habilitar o acceso a el. (Uso GitHub, pero estou seguro de que Travis CI pode integrarse con BitBucket, GitLab e outros servizos similares).

Cada vez que se inicia Travis CI, lánzase o servidor, executando os comandos especificados no ficheiro de configuración, incluíndo o despregamento das ramas do repositorio correspondentes.

▍Ciclo de vida laboral

Chamouse o ficheiro de configuración de Travis CI .travis.yml e almacenado no directorio raíz do proxecto, admite o concepto de eventos ciclo de vida tarefas. Estes eventos están enumerados na orde en que ocorren:

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

▍Probas

No ficheiro de configuración vou configurar o servidor local de Travis CI. Seleccionei o nodo 12 como idioma e dixen ao sistema que instalase as dependencias necesarias para usar Docker.

Todo o que está enumerado en .travis.yml, executarase cando se fagan todas as solicitudes de extracción a todas as ramas do repositorio, a non ser que se especifique o contrario. Esta é unha característica útil porque significa que podemos probar todo o código que entra no repositorio. Isto permíteche saber se o código está listo para escribirse na rama. master, e se romperá o proceso de construción do proxecto. Nesta configuración global, instalo todo localmente, executo o servidor de desenvolvemento de Webpack en segundo plano (esta é unha característica do meu fluxo de traballo) e executo probas.

Se queres que o teu repositorio mostre iconas de cobertura de proba, aquí Podes atopar breves instrucións sobre o uso de Jest, Travis CI e Overalls para recoller e mostrar esta información.

Polo tanto, aquí está o contido do ficheiro .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

Aquí é onde rematan as accións que se realizan para todas as ramas do repositorio e para as solicitudes de extracción.

▍Impregación

Partindo da hipótese de que todas as probas automatizadas se completaron con éxito, podemos, o que é opcional, implementar o código no servidor de produción. Xa que queremos facelo só para o código da rama master, dámoslle ao sistema as instrucións adecuadas na configuración de implantación. Antes de intentar usar o código que veremos a continuación no seu proxecto, gustaríame avisarlle de que debe ter un script real chamado para a súa implantación.

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

O script de implementación resolve dous problemas:

• Crea, etiqueta e envía a imaxe a Docker Hub mediante unha ferramenta de CI (no noso caso, Travis CI).
• Cargando a imaxe no servidor, parando o contedor antigo e iniciando un novo (no noso caso, o servidor funciona na plataforma DigitalOcean).

En primeiro lugar, cómpre configurar un proceso automático para crear, etiquetar e enviar a imaxe a Docker Hub. Todo isto é moi similar ao que xa fixemos manualmente, excepto que necesitamos unha estratexia para asignar etiquetas únicas ás imaxes e automatizar os inicios de sesión. Tiven dificultades con algúns detalles do script de implantación, como a estratexia de etiquetado, o inicio de sesión, a codificación da chave SSH, o establecemento de conexión SSH. Pero por sorte o meu mozo é moi bo co bash, como con moitas outras cousas. Axudoume a escribir este guión.

Entón, a primeira parte do script é cargar a imaxe a Docker Hub. Isto é bastante fácil de facer. O esquema de etiquetado que usei implica combinar un hash git e unha etiqueta git, se existe. Isto garante que a etiqueta é única e facilita a identificación do conxunto no que se basea. DOCKER_USERNAME и DOCKER_PASSWORD son variables de ambiente de usuario que se poden configurar mediante a interface Travis CI. Travis CI procesará automaticamente os datos sensibles para que non caian en mans equivocadas.

Aquí tedes a primeira parte do guión 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}

Cal será a segunda parte do script depende enteiramente do host que estea a usar e de como estea organizada a conexión con el. No meu caso, xa que uso Digital Ocean, uso os comandos para conectarme ao servidor doctl. Cando se traballe con AWS, utilizarase a utilidade aws, etcétera.

Configurar o servidor non foi especialmente difícil. Entón, configurei unha pinga baseada na imaxe base. Nótese que o sistema que escollín require unha instalación manual única de Docker e un lanzamento manual único de Docker. Usei Ubuntu 18.04 para instalar Docker, polo que se tamén estás a usar Ubuntu para facer o mesmo, podes seguir este guía sinxela.

Non falo aquí de comandos específicos para o servizo, xa que este aspecto pode variar moito en diferentes casos. Só vou dar un plan xeral de acción que se realizará despois de conectarse mediante SSH ao servidor no que se implementará o proxecto:

• Necesitamos atopar o contedor que se está a executar actualmente e detelo.
• A continuación, cómpre lanzar un novo contedor en segundo plano.
• Deberá configurar o porto local do servidor en 80 - isto permitirache entrar no sitio nun enderezo como example.com, sen especificar o porto, en lugar de usar un enderezo como example.com:5000.
• Finalmente, cómpre eliminar todos os contedores e imaxes antigos.

Aquí está a continuación do guión.

# Найти 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

Algunhas cousas ás que prestar atención

É posible que cando se conecte ao servidor mediante SSH desde Travis CI, vexa un aviso que lle impedirá continuar coa instalación xa que o sistema agardará a resposta do usuario.

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)?

Aprendín que se pode codificar unha chave de cadea en base64 para gardala nunha forma na que se poida traballar con ela de forma cómoda e fiable. Na fase de instalación, pode decodificar a chave pública e escribila nun ficheiro known_hosts para desfacerse do erro anterior.

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

Na práctica, este comando pode verse así:

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

E aquí está o que produce: unha cadea codificada en base64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Aquí está o comando mencionado anteriormente

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

O mesmo enfoque pódese usar cunha chave privada ao establecer unha conexión, xa que é posible que necesites unha clave privada para acceder ao servidor. Cando traballes coa chave, só tes que asegurarte de que está almacenada de forma segura nunha variable de ambiente Travis CI e de que non se mostra en ningún lugar.

Outra cousa a ter en conta é que pode ter que executar todo o script de implementación como unha liña, por exemplo, con doctl. Isto pode requirir un esforzo extra.

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

TLS/SSL e balance de carga

Despois de facer todo o mencionado anteriormente, o último problema que atopei foi que o servidor non tiña SSL. Xa que uso un servidor Node.js, para forzar traballar proxy inverso Nginx e Let's Encrypt, cómpre cambiar moito.

Realmente non quería facer toda esta configuración SSL manualmente, así que acabo de crear un equilibrador de carga e rexistrei os seus detalles en DNS. No caso de DigitalOcean, por exemplo, crear un certificado autoasinado de renovación automática no equilibrador de carga é un procedemento sinxelo, gratuíto e rápido. Este enfoque ten a vantaxe adicional de que facilita moito a configuración de SSL en varios servidores que se executan detrás dun equilibrador de carga se é necesario. Isto permite que os propios servidores non "pensen" en absoluto sobre SSL, pero ao mesmo tempo usen o porto como de costume 80. Polo tanto, configurar SSL nun equilibrador de carga é moito máis sinxelo e cómodo que os métodos alternativos de configuración de SSL.

Agora podes pechar todos os portos do servidor que acepten conexións entrantes, excepto o porto 80, usado para comunicarse co equilibrador de carga e co porto 22 para SSH. Como resultado, un intento de acceder directamente ao servidor en calquera porto que non sexa estes dous fallará.

Resultados de

Despois de que fixera todo o que falaba neste material, xa non me asustaron nin a plataforma Docker nin os conceptos de cadeas automatizadas de CI/CD. Puiden configurar unha cadea de integración continua, durante a cal se proba o código antes de entrar en produción e o código se desprega automaticamente no servidor. Todo isto aínda é relativamente novo para min, e estou seguro de que hai formas de mellorar o meu fluxo de traballo automatizado e facelo máis eficiente. Entón, se tes algunha idea sobre este asunto, fágame saber. me saber. Espero que este artigo che axude nos teus esforzos. Quero crer que despois de lelo, vostede aprendeu tanto como eu aprendín mentres descubría todo o que falaba nel.

PS No noso mercado hai unha imaxe Estivador, que se pode instalar cun só clic. Podes consultar o funcionamento dos contedores en Estudantes. Todos os novos clientes reciben 3 días de probas de balde.

Queridos lectores! Utilizas tecnoloxías CI/CD nos teus proxectos?

Fonte: www.habr.com