Посібник по Docker. Частина 3: Amazon Web Services, Travis CI та Elastic Beanstalk

З допомогою перших двох частин посібника з Docker ви вже освоїли основні способи докеризації веб-додатків. У третій частині посібника ви навчитеся розгортати докеризований проєкт в хмарі Amazon Web Services (AWS).

Посібник орієнтований на Docker і AWS, але для прикладу також розглядається дуже простий веб-додаток на базі React. Передбачається, що на вашому пристрої попередньо встановлений Node.js.

1. Створення додатка на React

Ініціалізуйте проєкт за допомогою наступної команди:

npx create-react-app frontend

Створиться проєкт з ім'ям frontend. Тепер, якщо у вас виникли проблеми з залежностями, просто переконайтеся, що ви їх встановили, виконавши команду:

sudo apt install 

Розглянемо деякі важливі команди для запуску додатка Node.js та з'ясуємо їх значення.

• npm run start → запуск сервера для розробки.
• npm run test → запуск тестування функціоналу проєкту.
• npm run build → збірка продуктивної версії продукту.

Тепер перейдіть у каталог frontend і спробуйте запустити команду зборки продуктивної версії, а потім — команду запуску сервера для розробки. Ви побачите, що React-додаток запускається в браузері автоматично!

Веб-додаток запущено і доступний в браузері!

2. Докеризація додатка на React

Тепер настав час почати працювати з Docker. Як ви вже бачили, команди npm build та npm start відповідають за версію для розробників та продуктивну версію відповідно.

Тому створимо Dockerfile для розробки і називатимемо його Dockerfile.dev, оскільки він відповідає за конфігурацію запуску версії для розробників.

Якщо ви не знаєте, як правильно писати Dockerfile, то прочитайте другу частину посібника з Docker.

Правильно написаний файл Dockerfile.dev буде виглядати наступним чином:

Dockerfile.dev

Тепер звичне docker build . не спрацює, оскільки Dockerfile.dev створений для цілей розробки. Тому вказуємо лише цей написаний Dockerfile для зборки:

docker build -f Dockerfile.dev .

Примітка: прапор -f ідентифікує конкретний Dockerfile.

Після виконання команди образ уже створено, але ви побачите нещо подібне:

Sending build context to Docker daemon 196.3MB

Таке повідомлення говорить про установку всіх залежностей веб-додатка, що не потрібно, оскільки вони встановлюються за допомогою користувацького Docker-образу. Тож, видаліть node_modules з проєкту та знову запустіть команду docker build.

Ви отримаєте ідентифікатор Docker-образу. Запустіть його в контейнері. Пам'ятайте про правильне зіставлення портів, інакше нічого не вийде.

docker run -it -p 3000:3000 

Виведення на екрані не змінилося. Виникають питання:

1. Що робити, якщо конфігурація веб-додатка зміниться?
2. Як вносити зміни в контейнер?

Відповідь криється в корисній технології зберігання файлів для контейнерів — Docker Volume. Спочатку розглянемо команду, а потім розберемо її.

docker run -it -p 3000:3000 -v /app/node_modules -v   
$(pwd):/app 

• $(pwd):/app — віддається команда на копіювання всіх файлів з поточної теки (зовні контейнера, на локальній машині) в внутрішній каталог контейнера з назвою /app всередині контейнера.
• PWD — ідентифікує поточну директорію.
• -v /app/node_modules — директорія node_modules в локальному каталозі (PWD) вже видалена. Ураховуючи це, в локальному каталозі більше немає папки node_modules для копіювання всередину контейнера.
  Тому вкажіть папку node_modules з контейнера.
• :/app — копіювання чогось всередину каталогу контейнера.

Тепер запустіть команду і оцініть зміни, які ви щойно внесли в додаток.

Неуспішна компіляція, немає дозволу

Здається, було отримано відмову в дозволі через користувача root. Потрібно змінити користувача на node і створити нову директорію, щоб скопіювати файли туди.

Файли в новій директорії

Створимо директорію /home/node/app перед інструкцією WORKDIR.

Це запобіжить проблемам з дозволами, оскільки WORKDIR за замовчуванням створить каталог, якщо його немає, і встановить право власності для користувача root.

Вбудовані Linux-команди chown встановлять права власності на скопійовані з локального середовища файли для користувача узла в контейнері. В результаті всі файли та каталоги в проєкті більше не належать користувачу root, а належать користувачу node.

Знову зібрайте користувацький образ і запустіть його в контейнері.

Оцініть зміни!

Поки що виглядає досить добре. Але чи пам'ятаєте ви ідею з Docker Compose з другої частини посібника з Docker? Реалізуємо задумку:

docker-compose up

Ви побачите ті самі результати.

3. Сервер виробничого рівня

До цього часу йшлося про сервер для розробки. Настав час створити контейнер для виробничого рівня. Для цього в Dockerfile реалізовано дві фази: Build Phase (фаза збірки) та Run Phase (фаза запуску).

• Крок 1.
  Створіть образ за допомогою команди docker build .:

• Крок 2.
  Запустіть образ у контейнері за допомогою команди docker run -it -p 8080:80:

Тепер ви готові до наступних кроків, а саме:

• Встановлення та налаштування з'єднання з GitHub.
• Підключення та налаштування TravisCI.
• Встановлення Amazon Web Services (потребує інформації про кредитну картку або попередньо придбаний доступ).

4. Підключення та налаштування з'єднання з GitHub

Передбачається, що ви знайомі з базовими сценаріями використання GitHub для безкоштовного хостингу програмного забезпечення. Тому створіть репозиторій у своєму акаунті та перемістіть веб-додаток до нього. Команди для переміщення коду в репозиторій наведені нижче:

git init
git add .
git commit -m “initial commit”
git remote add origin 
git push origin master

Ваш новенький репозиторій на GitHub виглядає приблизно так:

Репозиторій на GitHub

5. Встановлення Travis CI

Найпростіший спосіб пояснити Travis CI — він запускає тести програми при кожному коміті на GitHub.

Поведінка Travis CI налаштовується різними способами. Ви завжди можете вимкнути збірку на вибраних гілках. Сенс полягає в тому, щоб дуже швидко виявляти поломки, спричинені комітом, з подальшим виправленням до того, як помилки стануть проблемою.

Рекомендується запускати Travis CI для кожного репозиторію GitHub з модульними тестами на підтримуваному Travis CI мові програмування. Детальніше про Travis CI ви можете прочитати в документації.

Встановити Travis CI досить просто.
Коли все буде готово, ви побачите подібну сторінку:

Travis CI

Примітка: не забудьте надати Travis CI доступ до вашого репозиторію на GitHub!

Тепер потрібно налаштувати Travis CI так, щоб він тестував ваш код. Якщо тест пройде, програма буде розгорнута в хмарі Amazon Cloud Services:

Інструкції для TravisCI

Тепер перенесіть всі зміни в репозиторій проєкту на GitHub, а Travis CI займеться всім іншим:

Тести успішно виконані!

Зважаючи на все вищеописане, Travis CI — це ваша впевненість у тому, що додаток готовий до розгортання в хмарі.

6. Налаштування Elastic Beanstalk для хмари Amazon Cloud Services

Для початку слід зареєструвати акаунт в Amazon Cloud Services.

Тепер перейдіть до розділу Elastic Beanstalk, у розділ створення додатка. Elastic Beanstalk сам створить усе необхідне для розгортання проєкту! Конфігурація описана на скріншотах:

Тепер запустіть виробничу версію веб-додатка, як показано на скріншоті:

Нижче ви побачите посилання на Docker-env, яке представляє ваше веб-додаток, запущене на Elastic Beanstalk через Docker.

7. Запуск веб-додатка на AWS через Travis CI

Тепер настав час повідомити Travis CI, як правильно розгортати додаток на Amazon Cloud Services:

Обговоримо детальніше внесені в файл !.travis.yml зміни.

• Рядок 17, розгортання: команда вказує travis.yml, щоб автоматично розгорнути додаток на Elastic Beanstalk.
• Рядок 18, провайдер: оскільки передбачається застосовувати Elastic Beanstalk для розгортання проєкту веб-додатка, логічно, що elasticbeanstalk вказано як провайдер. Пам'ятайте, що потрібно писати обидва слова разом!
• Рядок 19, регіон: тепер, коли ви вже створили docker-додаток в Elastic Beanstalk, слід отримати статистику, наприклад, за посиланням
  Docker-env.eba-apszhzhm.ca-central-1.elasticbeanstalk.com. Подивіться на це посилання, там вказаний регіон ca-central-1. Встановіть регіон такий самий, як і в згенерованому посиланні.
• Рядок 20, додаток: вкажіть ім'я веб-додатка.
• Рядок 21, середовище: при створенні додатка створюється також і середовище Docker. Ви зможете побачити подробиці тут:

• Рядок 23, шлях: все буде зберігатися за вказаним шляхом, він створиться автоматично, коли ви вперше розгорнете своє додаток на Elastic Beanstalk. Прочитати шлях можна тут:

• Рядок 24, master: ієрархія фактично означає, що розгортання на Elastic Beanstalk виконується тільки при наявності оновлення в гілці master репозиторію GitHub.

Тепер потрібно створити користувача для подальшої аутентифікації в Travis CLI. Кроки створення користувача IAM:

1. Розділ IAM.
2. Додати користувача → вказати ім'я.
3. Вибрати “Ключ доступу”: “Програмний доступ”.
4. Надати Elastic Beanstalk повний доступ.
5. Створити користувача.

В результаті цих дій ви отримаєте облікові дані для Travis CI. Тепер перейдіть до налаштувань вашого проєкту в Travis CI.
Наприклад, https://app.travis-ci.com/github/Krypton3/docker-aws/settings.

Тепер додайте ключ доступу та секретний ключ у розділі змінних середовища.

Налаштування облікових даних Travis CI

Тепер додайте облікові дані у файл travis.yml вашого репозиторію:

Примітка: не забудьте відкрити вісімдесятий порт!

Dockerfile веб-додатка

docker-compose.yml для розгортання в Amazon Cloud Services

8. Висновки

Все майже готово до відправки. Ви щось забули? Тоді внесіть зміни в основну гілку. Travis CI знову зібере додаток і завантажить його в екземпляр інстанса EC2, створений Elastic Beanstalk. Добре, перед тим як показати вам магію, перевіримо все ще раз.

• Elastic Beanstalk

Переконайтеся, що стан екземпляра в нормі. Тут же написані назви додатка та середовища.

Додаток створено на 64-бітній версії Amazon Linux <версія>, з запущеним Docker. Тепер найважливіша частина: зверніть увагу на назву версії розгорнутого додатка Travis CI. Travis CI стиснув все вміст проєкту і завантажив zip-файл. Пам'ятаєте Bucket_name і Bucket_path?

• Облачний інстанс S3 (Bucket)

Travis CI запакував усе веб-додаток і помістив його в каталог docker/. Ці дії описані в конфігураційному файлі Travis CI. Крім того, для виконання цього кроку Travis CI потрібні облікові дані користувача AWS.

• IAM, Користувачі

Ви вже створили користувача з необхідними політиками доступу. Отримавши облікові дані, ви встановили їх у yml-файл Travis CI.

На цьому завершуємо роботу з AWS і Travis CI. Оцінимо магію!

Подивіться на URL-адресу. Додаток розміщено на AWS через Travis CI. Коли ви завершите, не забудьте зупинити всі інстанси AWS.

Читайте також:

• Реляційні бази даних у контейнерах Docker Compose
• Середовище розробки Entity Framework в Docker
• Як успішно реалізувати перевірку стану контейнера в Docker Compose

Читайте нас у Telegram, VK

Переклад статті Mahedi Hasan Jisan: Everything on Docker (Part lll)

Перекладено з: Руководство по Docker. Часть 3: Amazon Web Services, Travis CI и Elastic Beanstalk