Впровадження Docker для невеликого проекту Production

image

Ця стаття присвячена всім, хто ще думає, а чи варто мені морочитися з даною технологією не маючи велику віртуалку на одному з відомих хостерів і що в підсумку мені це дасть.
Тим кому це цікаво ласкаво просимо під кат.

Поспішаю так само відзначити, що дана стаття не є повноцінним керівництвом до дії, а лише описує один з можливих сценаріїв розгортання власного сервера.

Я маю великий досвід роботи з різного роду хостинг-провайдерами, можу вибирати майданчик як для великих так і малих проектів, знаю плюси та мінуси деяких майданчиків і маю свою власну думку. Так як це інформативна стаття а не рекламна то оперувати кінцевими іменами майданчиків ми не будемо. А задамо лише кілька умов:

  1. Варіант розвитку подій, чисто встановлена ОС, без зайвих компонентів, остання версія Docker, про те як її встановити докладно описано в документації.

  2. Ще один прекрасний спосіб використовувати ОС створену спеціально для контейнерів, наприклад CoreOS

Я зупинюся більш детально на варіанті № 2, так як саме його я вибрав для себе. Спочатку я вибирав між RancherOS і CoreOS але в період експлуатації першої я виявив безліч недоробок, проблем і незручностей, після чого вирішив відмовитися від її використання. Для тих кому цікаво, що це за ОС, той може легко впоратися з гуглом і пошукати інформацію про неї. Коротко це форк, але CoreOS але єдине всі системні служби це Docker контейнери. У цілому вони досить схожі, у кожної є свої фішки. Але недоліком ранчера для мене особисто стало відсутність хорошої документації, не можливість виконати ряд налаштувань через cloud-config і ще пара моментів утилізації пам'яті і системних ресурсів. Не кажучи вже про те, що структура файлової системи очищається на первісний стан окрім папок /opt /home. Так само одним з недоліків цього дистрибутива було те, що він за замовчуванням як і всі дистрибутиви Linux налаштований на тимчасову зону UTC але ось, можливості змінити цю справу в консолі після установки не було, і треба було повністю міняти консоль на будь-яку підтримувану, наприклад CentOS або Ubuntu, що не зовсім зручно, займає додатковий час і місце на дисках. Так само команди ініціалізації з cliud-config і user-config виконуються тільки в контексті нашої консолі. Отже специфічні. У CoreOS з цим все добре, можна зробити ось так:

cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

А після прокидати ці налаштування в будь-який з наших контейнерів. Ще однією проблемою було створення стартового скрипта, який повинен виконати Rancher після установки, скрипт благополучно створювався, але не виконувався. Хоча права були встановлені вірно. По мірі роботи з ним, виникало безліч дрібних питань, в слідстві чого вирішено було відмовитися від його використання. І вибрати CoreOS, яка до речі з коробки підтримує кластеризацію, чого в RancherOS поки немає зовсім. До того ж CoreOS вміє працювати як з контейнерами Docker так і зі своїми власними Rocket (rkt), що є звичайно ж плюсом. Ще однією особливістю CoreOS є авто оновлення, які вона запитує дуже часто, а в разі отримання такого вона обов'язково перезавантажується вся цілком, це звичайно можна виправити на етапі установки або у додатковому файлі конфігурації, але самі розробники рекомендують не змінювати це значення і дозволити ОС виконувати перезавантаження, коли у вас кластер, і сервіси автоматично мігрують по нодам це не так критично, але якщо у вас 1 сервер, то можливо така особливість буде критична до простою сервісу в кілька хвилин. Хоча чесно кажучи, завантаження відбувається дуже швидко.

В цілому обидва варіанти установки не мають ніяких відмінностей крім того, що одна ОС настільки мінімалістична, що не має навіть пакетного менеджера. Але ніхто не забороняє розгортати контейнери на звичному дистрибутиві. Я не хотів мати на хост машині якийсь зайвий софт, і вважаю, що будь утиліти або програми я можу встановити в потрібний мені контейнер, який я можу видалити в будь-який момент, не порушуючи цілісність самої ос.

Для початку встановимо CoreOS на наш сервер, якщо ваш оператор дозволяє завантажувати даний образ. Спочатку вам потрібно створити файл конфігурації cloud-config.yml у форматі YAML:

#cloud-config

hostname: вкажіть ім'я хоста 

# Далі налаштуємо синхранизацию часу з російськими серверами
write_files:
- path: /etc/systemd/timesyncd.conf
content: |
[Time]
NTP=0.ru.pool.ntp.org 1.ru.pool.ntp.org
# Після чого налаштуємо демон sshd
write_files:
- path: /etc/ssh/sshd_config
permissions: 0600
owner: root:root
content: |
# Мої налаштування демона.
UsePrivilegeSeparation sandbox
Subsystem sftp internal-sftp
PermitRootLogin yes
PasswordAuthentication no
ChallengeResponseAuthentication no
Port вкажіть бажаний порт
PrintLastLog yes
PrintMotd yes
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
PermitEmptyPasswords no
UseDNS no
UsePAM yes
coreos:
units:
# Налаштуємо наше мережеве підключення
- name: 10-static.network
runtime: true
content: |
[Match]
Name=ім'я мережевої карти в системі
[Network]
DNS=8.8.8.8
DNS=8.8.4.4
Address=192.168.100.100/24
Gateway=192.168.100.1
DHCP=no
# Встановимо тимчасову зону для нашого сервера Europe/Moscow
- name: settimezone.service
command: start
content: |
[Service]
ExecStart=/usr/bin/timedatectl set-timezone Europe/Moscow
RemainAfterExit=yes
Type=oneshot
# Змінимо сокет демона sshd на потрібний нам порт
- name: sshd.socket
command: restart
runtime: true
content: |
[Socket]
ListenStream=порт з конфига вище
FreeBind=true
Accept=yes
# Далі налаштуємо, щоб наш журнал сервера вирушав на інший сервер syslog в мережі
- name: journalctl-output.service
command: start
content: |
[Service]
Type=simple
Restart=always
TimeoutStartSec=60
RestartSec=60
ExecStart=/usr/bin/bash -c '/usr/bin/journalctl -o short -f | /usr/bin/ncat адреса_сервера порт'
ExecStop=
[Install]
WantedBy=multi-user.target

ssh_authorized_keys:
- тут ваші ключі, так як в подальшому авторизація буде можлива тільки по ключу

Я навмисно не налаштовую користувача, і інші параметри, так як привів мінімальну конфігурацію для того, щоб ваш сервер міг працювати приймати підключення безпечно і бути готовим до запуску потрібних контейнерів.

Для тих у кого не завелася мережа, після завантаження з інсталяційного диска CoreOS можна налаштувати мережі в ручну:

sudo ifconfig имя_карты add наш_ір
sudo route add -net 0.0.0.0/0 имя_карты
sudo echo nameserver 8.8.8.8 > /etc/resolv.conf

Перша строчка призначить нашій карті нашу адресу, друга пропише маршрут у всі мережі через цю карту, а третя сходинка нам пропише DNS сервера, на жаль в базовому образі файл resolv.conf не має посилань навіть на гугловый сервер, і без цієї строчки на етапі інсталяції ми отримаємо помилку.

Для того, щоб нам було простіше залити скільки завгодно великий конфіг на наш сервер, можна зробити невелику налаштування.

  1. Змінюємо пароль користувачеві core командою
    sudo passwd core
    ;
  2. Підключаємося до сервера по ssh;
  3. Робимо копіпаст конфига після команди
    vi cloud-config.yml
    .
Далі слід виконати установку командою:

sudo coreos-install -d /dev/sda -c cloud-config.yml

Де ми говоримо системі встановитися на перший диск, вона сама зробить розмітку томів, а файл конфігурації взяти це. До речі можна перемкнути гілку установки, за замовчуванням йде Stable але я не став цього робити.

Після установки робимо перезавантаження, і наша система готова до використання контейнерів Docker, про те, які і як використовую я, можу описати в наступній частині, якщо це буде цікаво.

Прошу сильно не штовхати, це моя перша стаття на Хабре) Всім дякую за увагу!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.