Эта статья посвящена всем, кто еще думает, а стоит ли мне заморачиваться с данной технологией имея не большую виртуалку на одном из известных хостеров и что в итоге мне это даст.
Тем кому это интересно добро пожаловать под кат.
Спешу так же заметить, что данная статья не является полноценным руководством к действию, а всего лишь описывает один из возможных сценариев развертывания собственного сервера.
Я имею большой опыт работы с различного рода хостинг провайдерами, могу выбирать площадку как для больших так и малых проектов, знаю плюсы и минусы некоторых площадок и имею свое собственное мнение. Так как это информативная статья а не рекламная то оперировать конечными именами площадок мы не будем. А зададим лишь несколько условий:
- Вариант развития событий, чисто установленная ОС, без лишних компонентов, последняя версия Docker, о том как ее установить подробно описано в документации.
- Еще один прекрасный способ это использовать ОС созданную специально для контейнеров, например 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 наш_ip
sudo route add -net 0.0.0.0/0 имя_карты
sudo echo nameserver 8.8.8.8 > /etc/resolv.confПервая строчка назначит нашей карте наш адрес, вторая пропишет маршрут во все сети через эту карту, а третья строчка нам пропишет DNS сервера, к сожалению в базовом образе файл resolv.conf не имеет ссылок даже на гугловый сервер, и без этой строчки на этапе инсталляции мы получим ошибку.
Для того, чтобы нам было проще залить сколь угодно большой конфиг на наш сервер, можно сделать небольшую настройку.
- Меняем пароль пользователю core командой
sudo passwd core; - Подключаемся к серверу по ssh;
- Делаем копипаст конфига после команды
vi cloud-config.yml.
Далее следует выполнить установку командой:
sudo coreos-install -d /dev/sda -c cloud-config.ymlГде мы говорим системе установиться на первый диск, она сама сделает разметку томов, а файл конфигурации взять этот. Кстати можно переключить ветку установки, по умолчанию идет Stable но я не стал этого делать.
После установки делаем перезагрузку, и наша система готова к использованию контейнеров Docker, о том какие и как использую я, могу описать в следующей части, если это будет интересно.
Прошу сильно не пинать, это моя первая статья на Хабре) Всем спасибо за внимание!
Комментарии (13)
antstar
24.01.2017 16:10+1Сергей, а можете ответить на эти вопросы:
а стоит ли мне заморачиваться с данной технологией имея не большую виртуалку на одном из известных хостеров и что в итоге мне это даст
В статье что-то не видно никаких возможных вариантов…
hamnsk
24.01.2017 16:28+2Это только первая часть статьи, если найдутся люди кому продолжение будет интересно, я допишу статью быстрей.
Лично для себя могу ответить, что имею услугу виртуального частного облака с 1 машиной, 1 цпу и 1024 МБ памяти, дисковое 30. Лично мне перевод своего сервера на контейнеры дало ощутимые плюсы. О которых я хотел рассказать позже, если вкратце, то приложения использующие разные виртуальные окружения через virtualenv теперь работают в контейнере, не зависимо друг от друга не прибегая к virtualenv, все пакеты стоят глобально. К тому же набор пакетов одного приложения не мешает набору другого приложения, и все это не лежит в системе. Удаляя контейнер с приложением или обновляя его система остается чистой. Миграция и переезд теперь будет в разы быстрей и проще. Всю инфраструктуру с нуля можно поднять за пару часов с учетом переноса данных.
Различные компоненты системы изолированны друг от друга это плюс к безопасности. Управление памятью стало гораздо проще, некоторые контейнера у меня имеют строго ограниченный лимит по памяти, что актуально на ее малом количестве.
Сейчас поддерживается кластеризация из коробки, следовательно при росте проекта я добавлю новый сервер перейдя на другой ТП, и перенесу сервисы очень быстро без простоев, либо сделаю балансировку.
Еще один из бонусов, эт то что не нужно помнить все этапы настройки сервера, конфиги и прочее, сервис поднимается с нуля запуском нужного контейнера. Конечно конфиги можно подменить, что в первом что во втором случае. Тут вопрос удобства.
D1abloRUS
24.01.2017 17:211024 МБ
По умолчанию в CoreOS нет swap, не было ли проблем с недостатком памяти?
некоторые контейнера у меня имеют строго ограниченный лимит по памяти
Если контейнер, а точнее процесс в контейнере начет выходить за эти лимиты, с ростом нагрузки или у вас ограниченны не влиящие на работу сервиса контейнеры? Скажем ограничили вы контейнер с бд по памяти, а ему надо стало больше, что в итоге? хотя это уже должно быть во второй статье рассказано.hamnsk
24.01.2017 19:21У большинства пользователей конфигурации в пределах 512-2048 мегабайт по памяти, если необходимо то swap раздел можно создать, для этого нужно описать это в нашем файле конфигурации, об этом сказано в документации, не уверен конечно что будет работа со свопом, не проверял просто.
Вы совершенно верно подметили, самый простой пример где можно получить нехватку памяти это ДБ, и действительно до использования контейнеров я у себя наблюдал такую ошибку. Сейчас те же сервисы в том же составе у меня живут на другом хостинге с теми же ресурсами но при этом Out of Memory я еще не разу не встречал, возможно все впереди. Как вариант можно внутри контейнера использовать forever или же supervisord, но в любом случае у меня есть контейнеры которым я гарантирую работу выделяя им нужный объем памяти.
D1abloRUS
24.01.2017 16:39+1Приветсвую,
Вариант развития событий, чисто установленная ОС, без лишних компонентов, последняя версия Docker, о том как ее установить подробно описано в документации.
Последняя версия docker всегда идет в alpha версии https://coreos.com/releases/
Еще один прекрасный способ это использовать ОС созданную специально для контейнеров, например CoreOS
Она скорее создана для создания кластера, ибо etcd, flannel и тд из коробки, т.е продвижение своих наработок в ОС, щас вот tectonic кстати.
RancherOS вроде даже 1.х.х версии не достигла, но вот она скорее более чиста в плане only docker. Но очень сыра.
Чем тот же debian не угодил? или если уж совсем «чистую» ос, то alpine? или чем для вас «чистота» ОС определяется?
Вы кстати забыли в конфиге:
- name: docker.service command: start
А то не будет автоматом стартовать, хотя systemctl enable docker.service должно работать, но данный параметр не сохраняется(вроде), могу ошибаться.
UTC там для класстера, это вполне нормально.
Кроме гугловских, добавили бы еще пару каких, или бы оставили те, что от хостера + гугл.
DNS=8.8.8.8 DNS=8.8.4.4
стоит ли мне заморачиваться с данной технологией имея не большую виртуалку
Виртуалка одна, как я понимаю, зачем тогда CoreOS? да и странный какой-то продакшен на одной вм… В общем статья во многом противоречет сама себе, на мой субъективный взгляд.hamnsk
24.01.2017 19:31Можно устанавливать последнюю версию, в стабильной ветке, не обязательно использовать альфа билды. То что CoreOS создана для кластера я упомянул это вскользь, планируя рассказать об этом в будущем. С Rancher вы правы, там все очень печально и нет даже билда 1.0.0, я тестировал 0.7 версию, насчет минимализма и docker only в стоке с дефолтной консолью возможно, но если начать менять консоли на дебиан, убунту центос, то их минималистичность становиться почти идентичной, так зачем тогда танцы с консолями.
Далее, о части конфига, это к сожалению или счастью не нужно. Сервис стартует автоматом, так уж устроена эта ОС. По поводу днс, я же говорил что конфигурация минимальна, но никто не мешает прописать больше. У меня прописано больше, я привел минимальный конфиг, только чтобы взлетело, чтобы можно было посмотреть что это такое. Ведь есть и те пользователи, которые проделают шаги только ради любопытства и не будут использовать ее возможно никогда.
Я не претендую на одобрение широкого взгляда большо специалиста, смысл данной статьи рассказать рядовому пользователю, что Docker это не страшно, а вполне понятно просто и быстро. возможно вы разработчик фрилансер, или сотрудник поддержки, а может владелец бизнеса и самостоятельно занимаетесь вопросом хостинга сайта, эта статья сделана простой для понимания не системными администраторами.
Я не собирался писать научный труд, для этого есть официальная документация, и другие статьи.
Виртуалка одна, но я упоминаю о частном приватном облаке, где виртуалки впоследствии может быть, две три пять по мере роста проекта.
Опять же не забываем про идеологию микросервисов. Для например чат бота, хватит такой виртуалки и ее действительно можно разместить в контейнере на минималистичном Alpine, но когда возникнет вопрос балансировки и отказоустойчивости, то тут изначальный завод на CoreOS выигрывает тем, что необходимо лишь будет донастроить пару служб и кластер готов.
Fortop
24.01.2017 19:11+1Где собственно ответы на поставленные вами же вопросы?
и что в итоге мне это даст.
Ну и плюсы какие-то странные для выбранной ОС
К тому же CoreOS умеет работать как с контейнерами Docker так и со своими собственными Rocket (rkt), что является конечно же плюсом.
То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.
Тогда в чем плюс-то?hamnsk
24.01.2017 19:35-1Где собственно ответы на поставленные вами же вопросы?
и что в итоге мне это даст.
Я собственно хотел рассказать об этом дальше, воспринимайте это как рассказ о неком пути человека, конец которому вы увидите позже.
Насчет плюсов, я описал один из возможных и вскользь упомянул о других. Разумеется далее я хотел рассказать подробней. Но не хочу писать сразу 1 большую статью, так как от прочтения таких устаешь и теряешь нить и суть повествования.
То есть статья о Docker же? Верно?
Значит умение работать с контейнерами Docker это явно не плюс.
А вот умение работать с какой-то индивидуальной хренью, которая нигде более не используется, записывать в плюсы тоже тупо.
Тогда в чем плюс-то?
Если эта хрень у вас не используется, это не значит что она тупая, у других она ой как используется, и как ее использовать расскажу позднее.
Статья о том как перевести продакшен на микросервисную архитектуру. Используя в частности Docker. А о различия Docker и Rocket я расскажу несколько позже.Fortop
24.01.2017 20:13+2- Краткое описание преимуществ требуется, раз уж вы подняли эти вопросы. Равно как и пояснение, что детали будут раскрыты в следующих статьях. В противном случае читающий остается в недоумении и читать следующие статьи просто не будет.
- Пишем не о Docker, а о Rocket — прямо об этом упоминаем(так и так, будем работать с докер-подобным контейнером со своей спецификой. Почему выбрали именно его — пояснить)
Статья о том как перевести продакшен на микросервисную архитектуру.
Вот это должно быть или в заголовке статьи или в первом же абзаце.
А не в комментариях.hamnsk
24.01.2017 22:28Учту ваши пожелания, но заголовок уже меня поздно, многие добавили в избранное для поиска в будущем.
Вообще я всегда за конструктивную критику, так как это моя первая публичная статья. Учиться никогда не поздно. Спасибо за замечания!
tzlom
Расскажите пожалуйста, каким образом управляете контейнерами? Приходилось ли поднимать виртуальные сети между серверами?
hamnsk
Что вы конкретно понимаете под управлением? Если создание нового, то это можно сделать с помощью командной строки, либо специальных сервисов, о которых я расскажу в следующих частях.
Далее если у вас услуга виртуального частного облака, вам VPN совсем не нужен. Если же сервера не в одной сети, то спсобов подъема VPN существует множество, и мануалов на эту тему достаточно много даже тут на хабре.
tzlom
Про сервисы с удовольствием почитаю.
VPN это понятно, но тот же докер имеет возможность построения оверлейных SDN сетей, думал может пользовались чем-нибудь таким. Мне нравится как работает их решение в docker cloud, но мне не нравится уровень контроля и процесс управления самого docker cloud поэтому ищу альтернативы.