part29-rus.md

Храните и извлекайте конфиденциальные данные для продакшен с помощью AWS Secrets Manager

Оригинал

Всем привет и добро пожаловать на мастер-класс по бэкенду.

В этой лекции мы узнаем, как использовать другой сервис: AWS Secrets Manager для управления переменными окружения и конфиденциальными данными для нашего приложения.

Если вы помните, на предыдущей лекции мы настроили продакшен базу данных на AWS RDS, и это URL

postgresql://root:tupExr0Gp4In4Ww4WHKR@simple-bank.czutruo2pa5q.eu-west-1.rds.amazonaws.com:5432/simple_bank

который мы использовали для доступа к нему. Когда мы развертываем простое банковское приложение в продакшен среде, мы хотели бы, чтобы оно подключалось к этой базе данных. Таким образом, мы должны заменить переменную DB_SOURCE в файле app.env реальным URL-адресом БД. Кроме того, нам нужно сгенерировать более надежный симметричный ключ для токена. Мы не должны использовать это тривиальное и легко угадываемое значение TOKEN_SYMMETRIC_KEY=12345678901234567890123456789012, верно?

Итак, идея заключается в том, что в рабочем процессе deploy GitHub Actions перед сборкой и отправкой образа Docker в ECR мы заменим все переменные окружения в файле app.env реальными значениями для продакшена. Таким образом, когда мы позже запустим Docker контейнер на сервере, он будет содержать правильные настройки для продакшен окружения. Замечательно, но вопрос в том, где мы должны хранить значения этих переменных окружения?

Конечно, мы не можем добавить их непосредственно в наш GitHub репозиторий, поскольку это не безопасно, не так ли? Одним из правильных решений является использование сервиса AWS Secrets Manager.

Сервис AWS Secrets Manager

Этот сервис позволяет нам хранить, управлять и извлекать любые конфиденциальные данные для нашего приложения. Это стоит довольно дешево, всего 0,4 доллара за каждую конфиденциальную переменную в месяц и всего 0,05 доллара за 10000 вызовов API, а также существует 30-дневный бесплатный пробный период. Поскольку мы планировали использовать AWS для развертывания нашего приложения, имеет смысл воспользоваться преимуществами этого сервиса для управления конфиденциальными данными. Хорошо, давайте создадим новую конфиденциальную переменную!

Существует несколько типов секретов, таких как учетные данные RDS, DocumentDB, Redshift или других баз данных. В нашем случае мы хотим хранить не только учетные данные БД, но и другие переменные окружения, поэтому я выберу «Другие типы конфиденциальных данных».

Затем в следующем разделе мы можем добавить столько пар ключ-значение, сколько захотим. Во-первых, давайте добавим DB_SOURCE. Я скопирую URL-адрес продакшен RDS базы данных из файла Makefile и вставлю его в это текстовое поле.

Затем давайте нажмем «Добавить строку», чтобы добавить новую пару «ключ-значение». Ключ будет DB_DRIVER, а значением будет postgres. Затем добавим новую строку для SERVER_ADDRESS. Его значение будет таким же, как и для локальной разработки: localhost, порт 8080. Обратите внимание, что это всего лишь внутренний адрес контейнера. Позже, когда мы на самом деле развернем приложение в Kubernetes, то узнаем, как настроить балансировщик нагрузки и доменное имя, которое будет направлять запросы API на правильный внутренний адрес контейнера. Хорошо, теперь давайте добавим еще одну строку для ACCESS_TOKEN_DURATION. Его значение будет равно 15 минутам. И, наконец, последняя строка для TOKEN_SYMMETRIC_KEY. Его значение должно быть строкой из 32 символов. Существует множество способов сгенерировать случайную строку из 32 символов. Сегодня я покажу вам, как это сделать с помощью команды openssl. Это довольно просто, мы просто запускаем:

openssl rand -hex 64

Используйте флаг -hex, чтобы сообщить, что нужно вывести строку только из шестнадцатеричных цифр. И в конце добавьте количество байт, скажем, 64 байта, чтобы получилась очень длинная строка. На самом деле эта строка содержит 128 символов, поскольку каждая шестнадцатеричная цифра занимает 4 бита или полбайта. В нашем случае нам нужно всего 32 символа, поэтому здесь мы используем символ pipe (|), чтобы воспользоваться получившимся результатом в следующей команде:

openssl rand -hex 64 | head -c 32 

которая означает, что нужно извлечь первые 32 символа. И вуаля, теперь у нас есть случайная строка для симметричного ключа токена. Скопируем и вставим в её в AWS Secrets Manager. Итак, теперь мы добавили все необходимые конфиденциальные переменные. Можно выбрать собственный, пользовательский ключ AWS KMS для шифрования данных, но это не обязательно. Сейчас мы можем просто использовать ключ шифрования по умолчанию.

На следующем шаге мы должны придумать название для наших конфиденциальных данных, чтобы мы могли легко к ним обращаться позже. Назовём их simple_bank. Вы также можете написать краткое описание, которое напомнит вам о том, какие значения хранятся там. При желании мы можем добавить какие-то теги, чтобы упростить управление, поиск или фильтрацию AWS ресурсов. И если захотим назначить права доступа к этим конфиденциальным данным. Но мы можем пока ничего из этого не делать.

Итак, давайте нажмем Next!

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

На последнем шаге мы можем просмотреть все настройки конфиденциальных данных. AWS также приводит нам пример кода для нескольких языков. Например, если вы хотите получить секретное значение непосредственно из своего кода, вы можете использовать этот код из примера и загрузить соответствующий пакет SDK (смотри рисунок). В нашем случае этого делать не нужно, поэтому давайте нажмем Store, чтобы сохранить конфиденциальные данные.

И вуаля, конфиденциальные данные успешно созданы. На этой странице мы можем нажать кнопку Retrieve secret value, чтобы отобразить все содержимое, хранящееся там.

Теперь когда конфиденциальные данные созданы, мы узнаем как модифицировать рабочий процесс GitHub deploy, чтобы получить значения и сохранить их в файле app.env. Я думаю, что для этого нам потребуется установить AWS CLI. Это очень мощный инструмент, помогающий нам легко взаимодействовать с сервисами AWS путём вызова API из терминала. Вы можете выбрать подходящий пакет в зависимости от вашей ОС. Я использую macOS, поэтому нажму на эту ссылку для загрузки установочного пакета. Затем откройте его, чтобы начать установку и следуйте инструкциям в пользовательском интерфейсе.

Теперь когда пакет AWS CLI успешно установлен, мы можем запустить эти 2 команды, чтобы убедиться в правильности его работы:

which aws

и

aws --version

Всё в порядке, никаких ошибок не возникло. Далее нам нужно задать учетные данные для доступа к вашей учетной записи AWS. Для этого просто запустите

aws configure

Нас просят ввести AWS Access Key ID и AWS Secret Access Key. Итак, вернемся в консоль AWS и откроем сервис IAM.

В левом меню нажмите Users. Здесь мы видим пользователя github-ci, которого мы настроили в одной из предыдущих лекций. На вкладке учетных данных мы видим Access Key ID, который используется для GitHub Action.

Но из соображений безопасности мы не можем увидеть для его Secret Access Key.

Поэтому нам нужно создать новый для локального использования. Нажмите на кнопку Create access key.

Давайте скопируем этот Access key ID и вставим его в терминал.

Затем нас попросят ввести Secret Access Key. Давайте нажмём на кнопку Show, чтобы увидеть значение и скопируем его. Затем вставьте его в терминал. Программа запросит название региона по умолчанию. Я введу eu-west-1, потому что это основной регион, который я сейчас использую. И, наконец, формат результата. Это формат данных, который мы хотим, чтобы AWS возвращал, при использовании интерфейса командной строки для вызова его API. Я буду использовать формат JSON.

Хорошо, теперь, если мы откроем папку .aws, то увидим 2 файла: credentials и config. Файл учетных данных содержит Access Key ID и Secret Access Key, которые мы только что ввели. default («по умолчанию») вверху файла - это название AWS профиля. При желании вы можете добавить в этот файл несколько AWS профилей с разными ключами доступа.

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

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

Хорошо, теперь мы можем вызвать API для управления конфиденциальными данными, чтобы получить наши значения. Вы можете запустить

aws secretsmanager help

чтобы прочитать его руководство по использованию.

Подкоманда, которую мы собираемся использовать, называется get-secret-value. Итак, давайте снова запустим команду для вызова справки с get-secret-value, чтобы увидеть её синтаксис.

aws secretsmanager get-secret-value help

По сути, нам нужно будет передать секретный идентификатор того конфиденциального значения, которое мы хотим получить. Это может быть либо ARN (Amazon resource name (название Amazon ресурса)) либо человекопонятное название конфиденциального значения. Найти ARN можно на соответствующей странице консоли AWS.

Человекопонятное название мы задали при создании этого конфиденциального значения, а именно simple_bank.

Хорошо, теперь вернитесь в терминал и запустите

aws secretsmanager get-secret-value --secret-id simple_bank

Произошла ошибка: "the github-ci user is not authorized to perform this request" («пользователь github-ci не авторизован для выполнения этого запроса»). Чего и следовало ожидать, поскольку мы ещё не предоставили права доступа позволяющие этому пользователю получить конфиденциальное значение.

На странице IAM мы видим, что пользователь github-ci входит в группу deployment, у которой есть доступ только к сервису Amazon ECR. Сейчас нам нужно предоставить этой группе доступ к сервису Secret Manager. Поэтому на странице этой группы давайте откроем вкладку Permissions, затем нажмите Add permissions, Attach Policies

Поищите по ключевому слову "Secret" в этом фильтре.

Вот, на рисунке показано, что нам нужно! Давайте выберем эти права SecretManagerReadWrite и нажмём Add permissions.

Хорошо, теперь все пользователи этой группы должны иметь доступ к сервису Secret Manager. Вернемся в терминал и запустим команду get-secret-value. Мы по-прежнему получаем ошибку об отказе в доступе. Я думаю, что разрешение, которое мы только что добавили, вступит в силу через некоторое время. Так что давайте немного подождем и попробуем использовать ARN вместо человекопонятного названием:

aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:eu-west-1:095420225348:secret:simple_bank-DI3Vdk

Хорошо, вызов успешно выполнен. Я попробую запустить команду ещё раз с человекопонятным названием: simple_bank.

aws secretsmanager get-secret-value --secret-id simple_bank

На этот раз запрос тоже успешно выполнен. Здорово!

Как видите, результат предоставляется в формате JSON. И нам доступно намного больше информации, чем просто хранящиеся значения. Нам нужно только значение, хранящееся в этом поле "SecretString".

Чтобы получить только это поле, нам просто нужно добавить аргумент --query к предыдущей команде и передать имя поля: "SecretString".

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString

Вуаля, теперь мы видим только данные, хранящиеся в конфиденциальном значении. Однако значение выдаётся в виде строки, а не объекта JSON. Мы должны добавить ещё один аргумент: «--output text» в команду, чтобы получить выходное значение в формате JSON, как видите здесь.

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text

Преобразовываем JSON объект в переменные окружения

Хорошо, но теперь, как мы можем преобразовать этот объект JSON в переменные окружения, чтобы их можно было сохранить в файле app.env? Существует очень хороший инструмент под названием "jq", который поможет решить эту проблему. jq — это легковесный и универсальный обработчик JSON для командной строки. Давайте посмотрим, как установить его. В Linux jq уже доступен в официальных установках Debian и Ubuntu, поэтому там нам не нужно ничего делать. Но по умолчанию он недоступен в MacOS, поэтому нам нужно его установить. В терминале давайте запустим:

brew install jq

Пока мы ожидаем завершения установки пакета с помощью brew, давайте заглянем в его руководство по использованию. Существует множество встроенных фильтров и операторов, которые мы можем использовать для преобразования входных данных JSON. Самый простой из них - это identity, представленная просто точкой. Этот фильтр просто возвращает всё, что он принимает в качестве входных данных, без изменений. Затем следует индекс идентификатора объекта или точка с последующим именем поля, которое мы хотим получить. Например, здесь мы вызываем jq '.foo', поэтому с этим входным JSON,

        jq '.foo?'
Input	{"foo": 42, "bar": "less interesting data"}
Output	42

он вернет значение поля "foo", равное 42. Если поля не существует, как в этом примере, он вернет null.

	    jq '.foo?'
Input	{"notfoo": true, "alsonotfoo": false}
Output	null

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

jq --version

чтобы проверить так ли это. Действительно, всё в порядке и установлена версия 1.6.

Теперь давайте запустим команду для получения конфиденциальных значений в виде объекта JSON и по цепочке её результат свяжем с командой jq, чтобы создать окончательный файл. Во-первых, я хочу преобразовать этот JSON объект типа "ключ-значение" в массив, где каждый объект будет отдельной переменной окружения. Для этого мы будем использовать оператор to_entries для jq.

	    jq 'to_entries'
Input	{"a": 1, "b": 2}
Output	[{"key":"a", "value":1}, {"key":"b", "value":2}]

Как видите в этом примере, он преобразует один объект с двумя ключами a, b в массив из двух объектов. Каждый объект имеет поле key и value. Это именно то, что нам нужно, поэтому здесь я собираюсь связать команду получения конфиденциального значения с jq to_entries.

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq 'to_entries'

Вуаля, теперь у нас есть пять разных объектов, в каждом из которых хранится одна отдельная переменная окружения. Затем мы должны перебрать их и преобразовать каждый объект в форму key=value, так как это тот формат, в которым будут храниться данные в файле app.env. Для такого преобразования мы будем использовать оператор map. Принцип его работы очень похож на функцию map в Python или Ruby. По сути, она перебирает список значений, применяет функцию преобразования к каждому из них и возвращает новый список из преобразованных значений.

	    jq 'map(.+1)'
Input	[1,2,3]
Output	[2,3,4]

Итак, здесь, в нашей команде, мы можем связать этот оператор to_entries с map, и скажем, если мы хотим получить только ключ объекта, мы будем использовать .key в качестве функции преобразования.

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq 'to_entries|map(.key)'

Тогда вуаля, мы получаем новый массив строк со всеми ключами.

Точно так же мы можем получить массив строк только со значениями, используя .value в качестве функции преобразования. Хорошо, но мы хотим, чтобы строка содержала как ключ, так и значение, разделенные знаком равенства. Для этого нам понадобится оператор интерполяции строк. По сути, это позволяет нам поместить выражение внутри строки, используя обратную косую черту, за которой следует пара скобок.

	    jq '"The input was \(.), which is one less than \(.+1)"'
Input	42
Output	"The input was 42, which is one less than 43"

В этом примере, первое выражение будет просто заменено входным значением, а второе - входным значением + 1. В нашем случае для этой функции map мы выведем строку, в которой первое выражение для интерполяции должно быть .key, за которым следует знак равенства, а затем второе выражение интерполяции - .value.

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq 'to_entries|map("\(.key)=\(.value)")'

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

	    jq '.[]'
Input	[{"name":"JSON", "good":true}, {"name":"XML", "good":false}]
Output	{"name":"JSON", "good":true}
{"name":"XML", "good":false}

Как вы можете видеть в этом примере, будут напечатаны только объекты. Давайте воспользуемся этим оператором! Я добавлю в конце символ "|", за которой следует итератор по элементам массива.

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq 'to_entries|map("\(.key)=\(.value)")|.[]'

Теперь вы видите, что остались только пять строк, квадратные скобки массива и запятые исчезли. Последнее, что нам нужно сделать, это избавиться от символов двойных кавычек, окружающих строку. Для этого нам просто нужно воспользоваться ключом -r (или --raw_output) в команде jq. С этим ключом получившиеся строки будут выведены без кавычек. Давай попробуем!

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]'

Отлично, теперь результат выглядит именно так, как мы хотели. Все, что нам нужно сделать, это перенаправить этот вывод, чтобы перезаписать файл app.env вот так!

aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' > app.env

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

Превосходно! Все содержимое файла было заменено переменными окружения для продакшена. Именно теми значениями, которые мы хранили в наших конфиденциальных данных.

Обновляем рабочий процесс deploy

Следующий шаг, который мы должны сделать, — подключить эту команду к рабочему процессу deploy GitHub CI перед сборкой Docker образа. Но сначала мне нужно откатить все изменения, внесённые в app.env и Makefile. Давайте запустим git checkout . в терминале. Итак, теперь все содержимое файлов было сброшено до первоначальной версии в ветке master.

Я создам новую ветку ft/secrets_manager, куда буду вносить новые изменения.

git checkout -b ft/secrets_manager

В файл deploy.yml давайте добавим новый шаг. Он будет называться Load secrets and save to app.env («Загрузить конфиденциальные данные и сохранить в app.env»).

- name: Load secrets and save to app.env
  run: aws secretsmanager get-secret-value --secret-id simple_bank --query SecretString --output text | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' > app.env

И он будет запускать команды, которые мы подготовили ранее, чтобы получить конфиденциальные значения из AWS, преобразовать их и сохранить в файле app.env. Нам не нужно устанавливать jq, потому что он уже доступен в образе Ubuntu, нам также не нужно настраивать учетные данные AWS CLI, потому что они уже настроены на предыдущем шаге рабочего процесса. Итак, давайте зафиксируем это изменение.

git commit -m "load secrets and save to app.env"

Отправим его на GitHub.

git push origin ft/secrets_manager

И откройте этот URL в браузере, чтобы создать новый пул-реквест. Это очень простое изменение, так что здесь особо код ревью не требуется. Давайте немного подождем, пока рабочий процесс, запускающий unit тесты завершится. Итак, как видно на рисунке они успешно пройдены.

Я объединю этот PR и удалю ветку с новым функционалом. Давайте откроем ветку master этого репозитория, в текущий момент будут запущены два рабочих процесса. Давайте откроем детальный отчёт для рабочего процесса deploy (смотри рисунок).

Хорошо, похоже, что шаг загрузки конфиденциальных данных уже успешно выполнен. И образ создаётся и отправляется в ECR. Отлично, всё шаги завершились без каких-либо ошибок.

Давайте откроем AWS консоль ECR сервиса. В репозитории simplebank мы видим только что отправленный туда новый образ.

Таким образом, всё отработало как мы и планировали! Но я хочу убедиться, что созданный нами образ действительно может взаимодействовать с рабочей БД, когда мы его запускаем. Поэтому я попытаюсь загрузить этот образ на свой локальный компьютер и запустить его. Давайте скопируем URL этого образа 095420225348.dkr.ecr.eu-west-1.amazonaws.com/simplebank:5750a6ef812d5775e9adc07708428dead6a54ceb и выполним docker pull с этим URL в терминале.

docker pull 095420225348.dkr.ecr.eu-west-1.amazonaws.com/simplebank:5750a6ef812d5775e9adc07708428dead6a54ceb

Загружаем Docker образ и запускаем локально

Предыдущая команда выдала ошибку, потому что Docker не может загрузить образ из этого приватного репозитория. Мы должны сначала войти в реестр AWS ECR, чтобы получить или отправить образ.

Для этого давайте поищем в браузере по ключевым словам aws ecr get login password. Мы используем AWS CLI версии 2, поэтому давайте откроем эту страницу. Эта команда позволит нам вызвать API AWS для получения токена аутентификации, который Docker может использовать для входа в наш приватный реестр. Итак, давайте скопируем эту команду aws ecr get-login-password

aws ecr get-login-password

и запустим её в терминале.

Вуяля, мы получили токен аутентификации. Теперь мы передадим этот токен команде docker login, а также AWS имя пользователя и пароль, используя аргумент stdin. И, наконец, URL-адрес нашего приватного Docker реестра.

aws ecr get-login-password | docker login --username AWS --password-stdin 095420225348.dkr.ecr.eu-west-1.amazonaws.com

Мы должны удалить название репозитория simplebank из URL-адреса.

Хорошо, авторизация прошла успешно. Теперь мы можем загрузить продакшен образ simplebank на локальный компьютер.

docker pull 095420225348.dkr.ecr.eu-west-1.amazonaws.com/simplebank:5750a6ef812d5775e9adc07708428dead6a54ceb

Как видно из рисунка, загрузка прошла без ошибок. Давайте выведем список образов.

docker images

Вот он! Теперь я запущу этот образ, чтобы посмотреть правильно ли он работает или нет.

docker run 095420225348.dkr.ecr.eu-west-1.amazonaws.com/simplebank:5750a6ef812d5775e9adc07708428dead6a54ceb 

К сожалению, произошла ошибок на шаге run db migration («выполнение миграций базы данных»): Error: URL cannot be empty («Ошибка: URL-адрес не может быть пустым»). Если мы откроем файл starts.sh, то увидим, что на этапе миграции базы данных мы используем переменную окружения DB_SOURCE. Но эта переменная определена только в файле app.env, который наше приложение считает при запуске. Она не установлена в качестве переменной окружения контейнера до запуска шага миграции БД. Вот почему возникает ошибка, что URL-адрес пуст. Чтобы исправить это, мы должны загрузить переменные из файла app.env в переменные окружения перед запуском миграций БД.

Если я сейчас выведу значение переменной окружения DB_SOURCE, то оно будет пустым.

Чтобы загрузить переменные в текущее окружение оболочки, я буду использовать команду source. Итак

source app.env

Теперь если я снова выведу DB_SOURCE, то значение больше не будет пустым.

Итак, давайте скопируем эту команду source и вставим её в файл start.sh непосредственно перед командой миграции БД.

echo "run db migration"
source app.env
/app/migrate -path /app/migration -database "$DB_SOURCE" -verbose

Обратите внимание, что внутри образа файл app.env хранится в рабочем каталоге /app. Поэтому здесь мы должны изменить путь на /app/app.env.

echo "run db migration"
source /app/app.env
/app/migrate -path /app/migration -database "$DB_SOURCE" -verbose

На этом всё! Думаю, это решит проблему.

Давайте обновим ветку master, загрузив последние изменения с GitHub. И создадим новую ветку с этим исправлением. Я назову её ft/load_env. Добавьте файл start.sh, который мы только что обновили, закоммитьте его с сообщением: "load environment variable before running db migration" («загружаем переменные окружения перед запуском миграций БД»). Затем отправьте её на GitHub.

Откройте эту ссылку в браузере, чтобы создать новый пул-реквест. Подождите немного, пока не закончат выполняться unit тесты. Затем объедините пул-реквест с master и удалите эту ветку. Теперь нам нужно дождаться завершения рабочего процесса deploy. Пока мы ждём, перейдите на ветку master на локальном компьютере. Загрузите последние изменения, которые мы только что объединили, с GitHub.

Хорошо, теперь давайте посмотрим, завершился ли рабочий процесс или нет. Он все еще работает. Наконец, он завершился (смотри рисунок).

В AWS консоли мы видим новый образ.

Я скопирую его URL. Затем запустите docker pull, чтобы загрузить этот образ на локальный компьютер.

docker pull 095420225348.dkr.ecr.eu-west-1.amazonaws.com/simplebank:059c54e72ea72b76d1539c1627a958940b09da1

Хорошо, теперь давайте запустим его, связав порт 8080 в контейнере с 8080 на локальном компьютере.

docker run -p 8080:8080 095420225348.dkr.ecr.eu-west-1.amazonaws.com/simplebank:059c54e72ea72b76d1539c1627a958940b09da1

Так мы сможем отправить API запрос, чтобы убедиться, что он работает правильно. Я собираюсь открыть Postman и послать первый запрос к API для создания нового пользователя.

Он успешно выполнен! Пользователь создан. Давайте подключимся к продакшен БД на AWS с помощью Table Plus и проверим данные таблицы users.

Итак, пользователь Алиса вставлен в качестве первой записи в эту таблицу. Итак, теперь мы можем сказать, что наш продакшен Docker образ правильно работает и готов к развертыванию.

На этом я завершаю сегодняшнюю лекцию о хранении и извлечении продакшен настроек с помощью AWS Secret Manager. Надеюсь она была интересной и приобретенные знания будут вам полезны.

На следующей лекции мы узнаем как развернуть продакшен образ, который мы подготовили сегодня, в Kubernetes кластере. До тех пор, желаю Вам получать удовольствие от обучения и до встречи в следующий раз!