Архив рубрики: О программировании

Однократные задачи в Kubernetes

Задачи в KubernetesПока что все примеры, что я делал для Docker Swarm и Kubernetes постов, строились вокруг какого-нибудь сервиса: веб-сервера, очереди сообщений или шины сообщений. В принципе, оно и не удивительно, весь тот же Docker Swarm построен вокруг концепции сервисов. Да что там Swarm, сами «микро-сервисы», из-за которых мы контейнеры в облака забрасываем, ни о чём не говорят?

Но не всё есть «сервис» в облаках. Есть и эпизодические задачи: рутинное обслуживание, запланированные задачи, конечные вычислительные таски — всё, у чего есть начало и вполне определённый конец.

Читать далее Однократные задачи в Kubernetes

Разбираем Kubernetes пример

Kubernetes пример

К моему глубочайшему удивлению, начиная с прошлой недели Kubernetes стал неотъемлемой частью моей работы. То есть теперь я не просто должен им интересоваться, его нужно ещё и понимать. А с этим, как можно судить по прошлому Kubernetes посту, есть проблемы. Вроде ж и пример тогда простой был, и по всем шагам прошёлся, но всё равно осталось какое-то ощущение недосказанности.

Читать далее Разбираем Kubernetes пример

Автоматическое масштабирование билд-серверов в GitLab CI

автоматическое масштабирование билд-серверов

На своём рабочем проекте Gitlab CI я использую уже где-то с год, и с большего всё было хорошо. Начинали мы с трёх билд-серверов (GitLab раннеров) под проект, а когда в команде появлялись новые люди, пытающиеся валом коммитов удивить начальство, либо билд-задач просто становилось больше, я добавлял ещё один сервак для возросшей нагрузки, и чувствовал себя героем. Но когда количество серверов пошло на второй десяток, то как-то стало понятно, что такой подход больше не работает.

Во-первых, всё равно случались пиковые нагрузки, с которыми билд-кластер справиться не мог. Хотя бы пару раз в неделю были периоды, когда количество билд-задач было раза в два больше, чем сервера могли вытянуть.

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

В общем, стало ясно, что существующий подход надо на что-то менять. Желательно на что-нибудь динамическое. И что здорово, в GitLab CI -таки встроено автоматическое масштабирование билд-серверов под текущую нагрузку. Её-то мы и будем сегодня пробовать.

Читать далее Автоматическое масштабирование билд-серверов в GitLab CI

Новая игрушка — бессерверное приложение

Способов, как задеплоить своё приложение, становится всё больше и больше. Не успели остыть Докер и его контейнеры, как появилась ещё одна идея: а что, если вместо упаковывания кусков приложения по контейнерам, мы отправим его логику прямиком в облако? Глупость ведь сказал ведь, правда? Но при этом практически у всех крупных провайдеров появилась такая штука как «функция-как-сервис» (FaaS), при помощи которой (а так же объектного хранилища и облачной базы данных) можно собрать полностью работоспособное приложение прямо в облаке — бессерверное приложение.

Конечно, сервер всё-таки где-то будет. Может, даже несколько. Но нас они совершенно не колышут, так как ими и всей инфраструктурой теперь управляет провайдер. Читать далее Новая игрушка — бессерверное приложение

Храним секреты приложения в Vault

HashiCorp Vault

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

Уже чуть позже, вгугливая, какие вообще есть инструменты для управления секретами, я наткнулся на HashiCorp Vault, и немного прифигел от того, как много вещей, оказывается, надо организовать и знать, чтобы эту задачу решить. Будучи всё ещё под впечатлением, сегодня я решил пройтись по основам Vault и, если получится, показать, насколько интересные решения умные люди нашли на этом поприще.

Читать далее Храним секреты приложения в Vault

Настройка кластера машин с Ansible

Настройка кластера Ansible

Мне очень понравилось, как было просто конфигурировать виртуальную машину с Ansible. Вот теперь думаю, а что, если машин было бы несколько? Ведь оригинальный пример был о нескольких машинах: один Consul сервер и два рабочих агента. Сервер уже готов, так что будет интересно довести пример до конца. Так что приступим.

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

Читать далее Настройка кластера машин с Ansible

Конфигурация VM с Vagrant и Ansible

Ansible vagrant

А я тем временем продолжаю выискивать, чем бы ещё автоматизировать настройку хостов. До сих пор я пользовался связкой Vagrant + bash/PowerShell для линуксовых или виндовых хостов, но каким-то странным образом пропустил тулзу, которая подходит под это дело лучше, чем просто скриптовать всё подряд, — Ansible. Она существует уже лет пять, и, как я заметил, превратилась практически в синоним фразы «автоматическая конфигурация». Сегодня, наконец, я её пожмякаю. Посмотрим, так ли уж Ansible удобнее, чем старый добрый bash.

Читать далее Конфигурация VM с Vagrant и Ansible

Непрерывная интеграция и развёртывание (CI/CD) в GitLab

GitLab logo

В прошлом месяце мы, наконец, переехали со своей старой CI/CD (continuous integration and delivery) системы домашней выделки на GitLab Community Edition, и этот факт делает моё лицо счастливым до сих пор. Всё-таки так приятно, когда и репозитории, и коммиты, и компиляция, и тесты, и результаты всего этого, и даже так кнопка «Одобрям-с», которая отправляет релиз-кандидата в репозиторий одобренных релизов — когда всё это лежит в одном месте и прекрасно интегрируется друг с другом.

От чего я действительно фанатею в Гитлабе, так это насколько легко в нём всё это настраивать. Настолько просто, что сегодня мы настроим полнофункциональную CI/CD систему от начала и до конца. От установки GitLab и до выкатывания релиза после успешных тестов.

Ну что, будем начинать?

Читать далее Непрерывная интеграция и развёртывание (CI/CD) в GitLab

Как перенести WordPress сайт в Docker

WordPress в Docker

Ни один из моих блогов на WordPress не установлен в Docker контейнерах, и об этом я жалею с самого момента их создания. Мне хватило всего пары недель, чтобы забыть, как именно настроены сервера, зачем на них включена та или иная фича, и теперь во время каждого апдэйда приходится молиться всем известным богам программирования, потому что если что-то пойдёт не так, я уже без понятия, как это разруливать. Даже просто перенести сайт на новый сервер было бы подвигом.

С Докер контейнерами таких проблем бы не было. Взял Dockerfile или docker-compose.yml, взял volumes с данными, перенёс на другую машину, и всё. Можно было бы даже запустить реплики блогов дома, чтобы на них экспериментировать, проверять апдэйты и надругивать новые фичи.

Но не всё потеряно. Прогрессирующее старпёрство мне уже не позволит просто так вот взять и выкатить Docker в свой «продакшен», но создать локальную докеризированную реплику одного из блогов определённо можно. А там, если всё пойдёт нормально, можно и в большой интернет. Читать далее Как перенести WordPress сайт в Docker

Локальный Docker реестр в Swarm

container stackВ одном из прошлых постов про проверку состояния контейнеров в Docker ближе к концу поста мне удалось запустить Swarm сервис из локально собранного образа. Ну как удалось.. Собрал и запустил. Но что меня удивило, Docker в Swarm режиме мне это позволил. Всё-таки в нём могло быть больше, чем один хост, а образ я создавал только на первом. Что если бы Swarm запустил сервис на ноде, где образа не было? Или отмасштабировал? Он же не стал бы автоматически копировать образы между хостами, так ведь? Или всё-таки стал бы?

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

Читать далее Локальный Docker реестр в Swarm