Делаем HTTPS сайтик с помощью Nginx Docker Compose Let’s Encrypt

(необязательно) определить virtual_port

Если обратный прокси-контейнер не может обнаружить порт, вы можете определить другую переменную среды VIRTUAL_PORT с именем порта, обслуживающего интерфейс, или любую другую службу, которую вы хотите проксировать, например «80» или «7765».

«три аккорда» докера

Для ежедневной работы с докером достаточно помнить всего лишь несколько команд.

Самая главная команда это, конечно, построение образа. Для того чтобы это сделать необходимо с помощью bash/CMD/PowerShell зайти в директорию, где находится Dockerfile и выполнить команду:

docker build -t your_image_name . 

Здесь после параметра -t задается имя вашего образа. Внимание — в конце команды после пробела точка. Эта точка означает что используется текущая директория. Образ можно пометить образ каким-нибудь тэгом (номером или названием). Для этого после имени поставить двоеточие и указать тэг.

docker build -t docker_account_name/image_name:your_tag . 

Здесь your_docker_account_name это имя вашего аккаунта в docker hub.

Если вы создали образ толко с локальным именем, не включающим в себя репозиторий, то пометить образ другим именем можно и после построения с помощью следующей команды:

docker tag image_name docker_account_name/image_name:your_tag

Для того чтобы отправить изменения в хаб теперь необходимо выполнить следующую команду:

docker push docker_account_name/image_name:your_tag

Перед этим необходимо зайти в ваш аккаунт докера. На Windows это делается из UI приложения, а вот на *nix это делается командой:

docker login

На самом деле трех команд недостаточно. Необходимо еще иметь возможность проверить работу контейнера. Команда, с помощью которой можно запустить контейнер выглядит так:

docker run -it -p 5000:80 image_name

Add our certificate to keychain access

Drag our newly created new-selfsigned.crt to theKeychain Access app.

Running Container With New Keys

Now we have our new crt and key files located in our new certkey folder. With them, we can use them with our new environment variables defined by our entrypoint.sh file:

Alpine base

To start, we’re going to use Alpine, because it’s the smallest footprint, and can be a good base for security as well. The reason is because there are less dependencies, which mean less chances of exploitation.

Changelog

• 11-11-2021 – Added gzip support and dropped TLS 1.0 and 1.1 #33
• 18-04-2021 – Added WebSocket support #22
• 29-05-2021 – Fixed duplicate redirect location after container restart #2
• 19-12-2021 – Support for $SITES variable
• 2-12-2021 – Dropped HSTS by default
• 25-11-2021 – Initial release

Committing pushing our code

git add .;
git commit -m "INIT: Initial commit."
git push origin master;

Configure nginx for ssl

We now need to associate our SSL certificate to our default.conf nginx file.

File:/etc/nginx/conf.d/default.conf

Connecting with github

In the root of our project, let’s get our repo setup:

Copying our files:

# certificate
docker cp nginx-alpine-ssl:/etc/ssl/certs/nginx-selfsigned.crt ~/Documents/nginx-alpine-ssl/config;# private key
docker cp nginx-alpine-ssl:/etc/ssl/private/nginx-selfsigned.key ~/Documents/nginx-alpine-ssl/config;# nginx configuration file
docker cp nginx-alpine-ssl:/etc/nginx/conf.d/default.conf ~/Documents/nginx-alpine-ssl/config;

Creating our dockerfile:

touch ~/Documents/nginx-alpine-ssl/Dockerfile;

File:/Dockerfile

Creating our entrypoint script:

This will be our script that will run at run time and we want to add some environment variables to add the ability to change the certificate and key out.

touch ~/Documents/nginx-alpine-ssl/config/entrypoint.sh

File:/config/entrypoint.sh

# Main shell script that is run at the time that the Docker image is run# Go to default.conf directory
cd /etc/nginx/conf.d;# ENV VARS
# A list of environment variables that are passed to the container and their defaults# CRT - double check that the file exists
export CRT="${CRT:=nginx-selfsigned.crt}";
if [ -f "/etc/ssl/certs/$CRT" ]
then
# set crt file in the default.conf file
sed -i "/ssl_certificate //c\tssl_certificate /etc/ssl/certs/$CRT;" default.conf;
fi# KEY - double check that the file exists
export KEY="${KEY:=nginx-selfsigned.key}";
if [ -f "/etc/ssl/private/$KEY" ]
then
# set key file in the default.conf file
sed -i "/ssl_certificate_key //c\tssl_certificate_key /etc/ssl/private/$KEY;" default.conf;
fi# Needed to make sure nginx is running after the commands are run
nginx -g 'daemon off;'; nginx -s reload;

Creating our new folders:

mkdir ~/Documents/nginx-alpine-ssl;
mkdir ~/Documents/nginx-alpine-ssl/config;

Docker hub automatic builds

This next part is to bring it all together with a GitHub repository and a connected Docker Hub repository that creates automatic builds for us to use.

Dockerfile

Next we’ll create a Docker file with some configuration files and an entrypoint.sh script.

For this we’ll create a new folder and copy our key and crt files to a newly created config folder, as long with our modified nginx configuration default.conf file.

Docker-nginx-auto-ssl

The simpliest solution to add SSL cert to your site

Generate new certificate & key

Next, we’ll generate new crt and key files in a new folder called certkey. To do this though, Mac OS doesn’t support -addext and instead of going the route of trying to reconfiguring our local openssl.conf file, we’ll just use an alpine docker image as a one time use to generate the keys we need.

Install nginx

Let’s install nginx now:

apk add nginx;

Make the directory that’s needed for nginx:

mkdir /run/nginx/;

Run nginx:

nginx;

Testing the server is running with curl

apk add curl;
curl localhost;# Expected output
# <html>
# <head><title>404 Not Found</title></head>
# <body>
# <center><h1>404 Not Found</h1></center>
# <hr><center>nginx</center>
# </body>
# </html>

It will show 404 because there is no html file and no configuration setup for nginx to point to a root directory to load files from.

Looking at the default.conf nginx file:

apk add nano;
nano /etc/nginx/conf.d/default.conf

Change it to the following, save and exit:

File:/etc/nginx/conf.d/default.conf

server {
listen 80 default_server;
listen [::]:80 default_server;# New root location
location / {
                root /var/www/localhost/htdocs;
                # return 404;
}        # You may need this to prevent return 404 recursion.
location = /404.html {
internal;
}
}

Restart nginx:

nginx -s reload;

Create an html in the htdocs folder:

Install openssl

Next we need to use OpenSSL to generate our key and certificate files.

apk add openssl;

Create our new key and crt files:

Making a build

To test the Dockerfile, let’s make a build by running the following in the root directory of the project:

docker build . -t nginxssltest;

Quick reminder: what is docker-compose?

docker-compose is a tool for defining containers and running them. It’s a great choice when you have multiple interdependent containers but you don’t need a full-blown container cluster like Kubernetes.

The official documentation puts it like this:

With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration

This guide requires docker-compose. If you don’t have it yet, take a look at the installation instructions and get it.Hint: If you’re installing docker-compose on CoreOS, it needs to go into /opt/bin instead of /usr/local/bin.

Requirements

You just need Docker for this.

Running our container

Let’s run our container and then do a curl test:

Testing different keys

Now that we see that it’s working, let’s test another domain with different generated keys.

First, let us modify out hosts file to add a new domain to it.

sudo nano /etc/hosts;

File:/etc/hosts

Trust domain with local computer

In order for us to trust the domain, we need to copy and place the crt (certificate) in our Keychain Access.

First we need to get a copy of that certificate in the Docker container. In a new Terminal window or tab, run:

docker cp nginx-alpine-ssl:/etc/ssl/certs/nginx-selfsigned.crt ~/Desktop;

Open up you Keychain Access app.

When the Keychain Access app loads up, on the left side bar, select Certificates. Drag the newly copied nginx-selfsigned.crt file from the Desktop to Keychain Access.

Next we need to make sure the certificate is trust by our computer. Double click on the newly added certificate, click the Trust dropdown and set “When using this certificate” to Always Trust.

Usage

Quick start to generate and auto-renew certs for your blog / application:

Docker-compose example:

start using

Using $sites with your own template

You have to override /usr/local/openresty/nginx/conf/server-proxy.conf either using volume or custom image. Basic templating is implemented for variables $SERVER_NAME and $SERVER_ENDPOINT.

Example template:

What each options means

To give some context as to what we’re doing in out openssl options:

Why ssl?

Pure and simple, security. There’s a bunch of other stuff as well, but mainly security.

Your own nginx.conf

If you have custom requirements and other customization options are not enough, you can easily provide your own configuration.

Example Dockerfile:

Minimal working nginx.conf:

Minimal nginx.conf with support for $SITES and conf.d includes

Build and run it using

Докеризация веб-приложения с nginx

В предыдущем разделе мы научились работать с нашим одностраничным приложением, используя Nginx в контейнере. Мы также можем отправлять наше приложение вкупе с Nginx в виде Docker-образа в контейнеры других сред. Контейнерные приложения дают ряд преимуществ: простота обновления, локализация сбоев, простая смена технологии.

Чтобы получить Docker-образ, создаём следующий Dockerfile:

# 1. Создаем приложение Angular
FROM node:alpine as builder

WORKDIR /app
COPY package.json package-lock.json ./
ENV CI=1
RUN npm ci

COPY . .
RUN npm run build -- --prod --output-path=/dist

# 2. Развертываем приложение Angular на NGINX
FROM nginx:alpine

# Заменяем дефолтную страницу nginx соответствующей веб-приложению
RUN rm -rf /usr/share/nginx/html/*
COPY --from=builder /dist /usr/share/nginx/html

COPY ./.nginx/nginx.conf /etc/nginx/nginx.conf

ENTRYPOINT ["nginx", "-g", "daemon off;"]

Этот Dockerfile включает две фазы создания Docker-образа. Сначала он стягивает образ node:alpine для создания приложения Angular, которое публикуется по выходному пути /dist.

Далее он переключается на образ nginx:alpine, заменяет дефолтный корень приложения Nginx приложением Angular и копирует кастомный файл nginx.conf в систему Nginx.

В последней строке указывается точка входа образа для команды: nginx -g daemon off;. Это гарантирует, что Nginx останется «на переднем плане», так что Docker сможет правильно отслеживать процесс (в противном случае контейнер остановится сразу после запуска).

С помощью описанного Dockerfile мы можем создать образ Docker и запустить его в контейнере, используя следующие команды:

docker build -t angular-nginx-docker .
docker run -d -p 80:80 angular-nginx-docker

Готово! В этой статье мы продемонстрировали, как обслуживать простые веб-приложения с использованием Nginx в контейнере, кратко рассказали о файле конфигурации для Nginx, а также о том, как можно вместе упаковать в один образ и приложение сервера, и frontend-часть.

***

Запуск контейнера через реверс прокси-сервер

Дело в том, что сами приложения .NET Core используют свой веб-сервер Kestrel. Этот сервер не рекомендуется для работы на production. Почему? Есть несколько объяснений.Если есть несколько приложений, которые делят между собой IP и порт, то Kestrel не сможет распределять трафик.

Кроме того, реверс прокси-сервер предоставляет собой дополнительный слой безопасности, упрощает балансировку нагрузки и настройку SSL, а также лучше интегрируется в существующую инфраструктуру. Для большинства разработчиков самой главной причиной необходимости реверс-прокси, является дополнительная безопасность.

Для начала восстановим начальную конфигурацию Dockerfile. А после разберёмся с файлом docker-compose.yml и попробуем запустить наш сервис в одиночку. Формат файла yml читается так «ямл» и является аббревиатурой то ли от «Yet Another Markup Language», то ли от «YAML Ain’t Markup Language». То ли еще один язык разметки, то ли не язык разметки совсем. Как-то все не определенно.

Мой файл docker-compose созданный по умолчанию выглядит так:

version: '3.4'

services:
  dockerservicedemo:
    image: ${DOCKER_REGISTRY}dockerservicedemo
    build:
      context: .
      dockerfile: DockerServiceDemo/Dockerfile

Файл docker-compose.override.yml добавляет в конфигурацию несколько настроек:version: ‘3.4’

services:
  dockerservicedemo:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "80"

Построить созданное решение мы можем с помощью docker-compose build, в вызвав команду docker-compose up мы запустим наш контейнер. Все работает? Тогда переходим к следующему шагу. Создаем файл nginx.info. Конфигурация будет примерно следующая:

Запускаем приложение на nginx в docker-контейнере

Nginx и Docker на удивление хорошо работают вместе. Вместо того чтобы устанавливать Nginx на нашу машину напрямую, мы будем запускать его в Docker на примере nginx:alpine.

Образ nginx:alpine очень производителен, хотя занимает лишь около 20 Мб дискового пространства. Для интерактивного запуска образа nginx: alpine в контейнере мы выполняем следующую команду:

docker run -it -p 80:80 
    -v /$PWD/dist/angular-nginx-docker://usr/share/nginx/html:ro 
    nginx:alpine

Использование образа в работе с языками программирования

Если язык программирования позволяет исполнять установленные в системе программы, то задача использования ГОСТ-алгоритмов проще всего решается копированием бинарников собранных openssl и curl в конце Dockerfile языка программирования с использованием multi-stage build. Например:

FROM rnix/openssl-gost AS openssl-gost

# Replace with any other image based on Debian x86_64
FROM debian:stretch-slim

COPY --from=openssl-gost /usr/local/ssl /usr/local/ssl
COPY --from=openssl-gost /usr/local/ssl/bin/openssl /usr/bin/openssl
COPY --from=openssl-gost /usr/local/curl /usr/local/curl
COPY --from=openssl-gost /usr/local/curl/bin/curl /usr/bin/curl
COPY --from=openssl-gost /usr/local/bin/gostsum /usr/local/bin/gostsum
COPY --from=openssl-gost /usr/local/bin/gost12sum /usr/local/bin/gost12sum

Даже необязательно копировать в /usr/bin, это можно сделать в любой каталог, а затем вызывать из вашей программы, передав полный путь и все аргументы.

Не привязывать ни к какому порту

В контейнере может отсутствовать порт, обслуживающий интерфейс. Контейнер обратного прокси-сервера автоматически обнаружит это.

Небольшие приготовления: создаём веб-приложение

Для начала нам нужно какое-то веб-приложение, которое будет обслуживаться сервером Nginx. Вы можете использовать любой JavaScript-фреймворк, в нашем примере мы используем демо-проект Angular:

ng new angular-nginx-docker --minimal
cd angular-nginx-docker
ng build --prod

В результате выполнения указанных команд будет создано новое приложение Angular, находящееся в папке $PWD/dist/angular-nginx-docker. Этот каталог содержит файл index.html и несколько типичных для одностраничного приложения JavaScript и CSS файлов. Приложение, весь код и команды из этой статьи находятся в GitHub-репозитории.

О докере

О микросервисной архитектуре слышали практически все. Сам концепт разбития приложения на части не сказать чтобы новый. Но, новое – это хорошо забытое и переработанное старое.

Если постараться рассказать об архитектуре в нескольких словах, то веб приложение разбивается на отдельные унитарные части — сервисы. Сервисы не взаимодействуют между собой напрямую и не имеют общих баз данных. Это делается для возможности изменять каждый сервис без последствий для других. Сервисы упаковываются в контейнеры. Среди контейнеров правит балом Docker.

Для того, чтобы описать что такое Docker очень часто упрощенно используют термин «виртуальная машина». Сходство определенно есть, но говорить так неправильно. Проще всего это различие понять, посмотрев на следующие изображения с официальной документации докера:

Контейнеры используют ядро текущей операционной системы и делят его между собой. В то время как виртуальные машины с помощью hypervisor используют аппаратные ресурсы.Образ/Image докера это read-only объект, который, по сути, хранит в себе шаблон для построения контейнера.

Контейнер — это среда в которой выполняется код. Образы хранятся в репозиториях. Например, официальный репозиторий Docker Hub позволяет хранить только один образ приватно. Впрочем, это бесплатно, поэтому даже за это нужно их поблагодарить.

Докер не является единственным представителем контейнеризации. Кроме его существуют и другие технологии. Например:

rkt (произносится как ‘рокет’) от CoreOS

LXD (произносится как ‘лексди’) от Ubuntu

Windows Containers — ни за что не угадаете от кого.

Теперь, когда мы ознакомились с теорией, давайте перейдем к практике.

Определите правильные переменные среды

Контейнер, который будет обслуживать интерфейс, должен будет определить две переменные среды.

• VIRTUAL_HOST: для создания конфигурации обратного прокси
• LETSENCRYPT_HOST: для создания необходимых сертификатов

Вы можете запустить веб-службу через контейнер докеров с обратным прокси следующим образом (не копируйте и вставляйте его):

Поддержка гост-алгоритмов в php

PHP, конечно, позволяет делать вызовы системных команд, используя, например, exec. Но, глядя на то, как собирается PHP-FPM в Dockerfile, мне показалось, что можно легко собрать PHP с кастомными сборками OpenSSL и cURL. Как оказалось дальше, я ошибся, что это легко. Всё равно собрал.

По какой-то причине, я начал с PHP-FPM 7.1. Идея была в том, чтобы использовать multi-stage build. Для этого надо заменить в их Dockerfile инструкцию FROM на мою FROM rnix/openssl-gost AS openssl-gost, затем прописать копирования собранных openssl и curl до начала сборки самого php и, наконец, указать в опции сборки путь до этих библиотек –with-openssl-dir=/usr/local/ssl и –with-curl=/usr/local/curl заменив оригинальные.

Сюрпризы ждали отовсюду. Одним из значительных было то, что при сборки php 7.1 используется pkg-config, а явная установка libcurl4-openssl-dev, libssl-dev прописывали в pkg-config версии из пакетов. В результате собиралось не то, что нужно. Если убрать их установку, то /configure php падал, ссылаясь на отсутствие openssl в pkg-config.

Пришлось дополнительно копировать из кастомных сборок openssl и curl их lib/pkgconfig /*. После десятков таких сюрпризов сборка начала проходить. Дальше выяснилось, что зависимости устанавливали openssl, тем самым перезатирая ранее скопированный бинарник моей кастомной сборки. Пришлось дополнительно копировать его в самом конце. Но это не всё.

Поддержка гост-сертификатов в nginx

Возможность работать из языков программирования это уже много, но хотелось еще две возможности:

Предпосылки

Чтобы легко начать работу с этой статьей, вам потребуются следующие знания. Но вы можете обойтись и без них.

Примеры использования openssl gost-engine

Не буду сильно вдаваться в подробности работы с докер-образами, лишь приведу одну команду для начала работы внутри образа:

docker run --rm -i -t rnix/openssl-gost bash

Для начала можно убедиться, что алгоритмы GOST2021-GOST8912-GOST8912 и GOST2001-GOST89-GOST89 есть в списке поддерживаемых:

openssl ciphers

Сборка openssl, gost-engine, curl

Сборка стороннего продукта для тех, кто делает это редко, может быть нетривиальной задачей. Для сборки OpenSSL, GOST-engine и cURL пришлось разобраться с кучей опций и перепробовать несколько комбинаций версий. Если в Dockerfile вы заметите странное, то, скорее всего, это осталось от таких экспериментов.

Я зафиксировал все версии проектов для сборки, чтобы исключить ситуацию, что из-за обновления что-то перестанет работать. Например, я собирал OpenSSL 1.1.0h GOST-engine и команда openssl ciphers не содержала GOST-алгоритмов, хотя openssl engine показывала GOST-engine в списке.

Собирая сам GOST-engine, я не сразу обратил внимание на наличие файла INSTALL.md в master-ветке, потому что собирал из ветки openssl_1_1_0 по неизвестно откуда взятой документации. Та версия собиралась с кастомной сборкой OpenSSL командой

cmake -DCMAKE_C_FLAGS='-I/usr/local/ssl/include -L/usr/local/ssl/lib' ..

Но master-ветка так собираться перестала, появились ошибки об отсутствии DOPENSSL_ROOT_DIR и подобное. В итоге решение было найдено и зафиксировано.

Для сборки cURL с кастомной сборкой OpenSSL гораздо больше документации, тем не менее, документация успевала устаревать, и с опциями пришлось много экспериментировать.Результат работы выложен здесь.Образ запушен в Docker Hub.

Создание проекта с поддержкой докера

Докер это, конечно Linux-овый продукт, но при необходимости можно его использовать при разработке под Mac или под Windows. При создании проекта в Visual Studio для добавления поддержки докера достаточно поставить флажок Enable Docker Support.

Поддержку докера можно добавить и в существующий проект. Добавляется она в проект таким же образом, как и добавляются различные новые компоненты. Контекстное меню Add – Docker Support.

В случае, если на вашей машине установлен и запущен докер, будет автоматически открыта консоль и выполнена команда

docker pull microsoft/aspnetcore:2.0

которая запускает процесс скачивания образа. Этот образ фактически является заготовкой на основе которого будет создан ваш образ. ASP.NET Core 2.1 использует уже другой образ – microsoft/dotnet:sdk

В директории с решением для вас будут созданы автоматически следующие файлы:.dockerignore (исключение файлов и директорий из образа докера), docker-compose.yml (с помощью этого файла можно сконфигурировать выполнение нескольких сервисов), docker-compose.override.yml (вспомогательная конфигурация docker-compose), docker-compose.dcproj (файл проекта для Visual Studio).

В директории с проектом создастся файл Dockerfile. Собственно, с помощью этого файла мы и создаем свой образ. По умолчанию (в случае, если проект называется DockerServiceDemo) он может выглядеть примерно так:

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src

COPY DockerServiceDemo/DockerServiceDemo.csproj DockerServiceDemo/
RUN dotnet restore DockerServiceDemo/DockerServiceDemo.csproj
COPY . .
WORKDIR /src/DockerServiceDemo
RUN dotnet build DockerServiceDemo.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish DockerServiceDemo.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "DockerServiceDemo.dll"]

Начальная конфигурация для .NET Core 2.0 не позволит вам сразу построить образ с помощью команды docker build. Она настроена на то, что будет запущен файл docker-compose из директории уровнем выше. Для того чтобы построение происходило успешно Dockerfile можно привести к подобному виду:

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY DockerServiceDemo.csproj DockerServiceDemo.csproj
RUN dotnet restore DockerServiceDemo.csproj
COPY . .
WORKDIR /src
RUN dotnet build DockerServiceDemo.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish DockerServiceDemo.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "DockerServiceDemo.dll"]

Все что я сделал, это убрал лишнюю директорию DockerServiceDemo.

Если вы используете Visual Studio Code, то файлики вам придется генерировать вручную. Хотя в VS Code и имеется вспомогательный функционал в виде расширения Docker Добавлю ссылку на мануал о том как работать с докером из VS Code – Working with Docker. Да, статья на английском, но она ведь с картинками

Ссылки

1. Репозиторий со всеми решениями на GitHub
2. Образ на Docker Hub с OpenSSL GOST cURL
3. ГОСТ Р 34.10-2021 на Википедии со списком сертифицированных решений
4. Репозиторий GOST-engine
5. О возможностях и ограничениях GOST-engine
6. Пример того, как решают вопрос в продакшн-окружении

Установите let’s encrypt для конкретного контейнера

Вы можете переопределить переменную DEFAULT_EMAIL и установить конкретный адрес электронной почты для сертификата (ов) домена/поддомена конкретного контейнера/веб-службы, установив идентификатор электронной почты в переменную среды LETSENCRYPT_EMAIL.

Шаг 1. настройте контейнер обратного прокси nginx

Начните с настройки обратного прокси-сервера nginx. Создайте каталог с именем “reverse-proxy” и переключитесь в него:

mkdir reverse-proxy && cd reverse-proxy

Создайте файл с именем docker-compose.yml, откройте его в своем любимом текстовом редакторе на базе терминала, таком как Vim или Nano.

Для обратного прокси-сервера nginx мы будем использовать образ jwilder/nginx-proxy. Скопируйте и вставьте в файл docker-compose.yml следующее:

version: "3.7"

services:

    reverse-proxy:
        image: "jwilder/nginx-proxy:latest"
        container_name: "reverse-proxy"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/tmp/docker.sock:ro"
        restart: "always"
        networks: 
            - "net"
        ports:
            - "80:80"
            - "443:443"

Теперь давайте пройдемся по важным частям файла создания:

Использование сети, определяемой пользователем, очень важно. Это поможет изолировать все контейнеры, которые должны быть проксированы, а также позволит обратному прокси-контейнеру перенаправлять клиентов в их желаемые/предполагаемые контейнеры, а также позволит контейнерам взаимодействовать друг с другом (что невозможно с сетью моста по умолчанию. если iccне установлено значение trueдля демона).

Имейте в виду, что YML очень требователен к табуляциям и отступам.

Шаг 2. настройте контейнер для автоматического создания сертификата ssl

Для этого вы можете использовать образ контейнера jrcs/letsencrypt-nginx-proxy-companion.

В том же файле docker-compose.yml, который вы использовали ранее, добавьте следующие строки:

Шаг 4. запустите другие сервисные контейнеры с обратным прокси

Процесс настройки других контейнеров, чтобы их можно было проксировать, ОЧЕНЬ прост.

Заключение

Мной изучена проблема работы с ГОСТ-алгоритмами в системах Linux, предоставлено решение в виде docker-образов, все это сопровождено документацией и примерами. Решение оформлено в виде репозитория на GitHub.

Стоит сказать о безопасности использования такого решения. Главное, не стоит доверять образам на Docker Hub, даже если там написано Automated Build. Я все равно могу собрать образ с любыми правками всех используемых библиотек и систем и запушить его в свой Docker Hub под любым тегом.

Собирая образ самостоятельно, вы можете убедиться, что в код не попали злонамеренные правки, потому что сборка происходит только из открытого кода, который доступен для просмотра всем желающим. Тем не менее, это не гарантирует, что в нем нет ошибок и уязвимостей.