OrangeDevOps

2021-04-08 13:31:05 DevOpsConf 2021
Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf.

30 мая и 1 июня 2021г, Москва.

Обсуждаем актуальные вопросы из сферы DevOps:
Как закладывать отказоустойчивость систем на этапе проектирования и разработки
Как эффективно обеспечивать жизненный цикл систем в промышленной эксплуатации
Как помогать пользователям, что бы они были довольны использованием систем
Как быстро обнаруживать инциденты и не желательное поведение систем
Как быстро поставлять фичи

Подробности и билеты https://devopsconf.io/moscow/2021 Открыть/Комментировать

2021-04-08 13:31:05 Чисто Devops-конференций не так уж много. Из тех что нравятся и очень часто смотрю - это доклады HighLoad и DevOpsConf на ютубе. Это честное личное мнение, а не реклама. Реклама будет ниже.
А вы посещаете профессиональные конференции? Открыть/Комментировать

2021-04-08 08:00:33 Грех 3. Вы используете healthy для координации запуска службы

Основная причина, по которой эта проблема такая важная, заключается в том, что Docker или Docker Compose не поддерживают ее. Версия 2.1 формата docker-compose имела параметр depends_on для которого можно было установить значение service_healthy. Кроме того, каждая служба может иметь команду проверки работоспособности, которая может сообщать docker-compose - healthy. Что ж этого больше нет в версии 3.0 и никакой замены для него не предлагается.

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

Это становится немного более обременительным когда вы запускаете интеграционный тест и процедуры, предназначенные для инициализации тестовой среды (например, предварительное заполнение базы данных некоторыми тестовыми данными) службы в конечном итоге могут не запуститься до того, как другая служба будет готова. Таким образом, аргумент о том, что «в любом случае он должен быть устойчивым в производственной среде», здесь не совсем применим, потому что код для заполнения БД тестовыми данными никогда не используется в производственной среде.

В таких случаях вам нужно что-то, что ждет готовности сервисов. Docker рекомендует использовать wait-for-it, Dockerize или wait-for. Однако обратите внимание, что готовность порта не всегда является признаком того, что служба готова к использованию. Например, в интеграционном тесте с использованием определенной базы данных SQL с определенной схемой порт становится доступным при инициализации базы данных, однако тест может работать только после применения определенной миграции схемы. Сверху могут потребоваться проверки для конкретного приложения.
#docker Открыть/Комментировать

2021-04-07 08:00:38 Грех 2. Вы привязываете порты к 0.0.0.0 хоста.
Привязка портов как 8080:8080. На первый взгляд это выглядит безобидно. Но дьявол кроется в деталях. Эта чрезвычайно распространенная привязка портов не просто перенаправляет порт контейнера на локальный хост - она перенаправляет его, чтобы он был доступен на каждом сетевом интерфейсе в вашей системе, включая все, что вы используете для подключения к Интернету.
Это означает, что очень вероятно, что ваши контейнеры разработки постоянно прослушивают вашу локальную сеть - когда вы дома, когда вы в офисе или когда вы находитесь в McDonald’s. Это всегда доступно. Это может быть опасно. Не делай этого.
«Но я использую ufw, мои порты по умолчанию недоступны».
Это может быть правдой, но если вы используете эту настройку docker-compose в команде, у одного из ваших товарищей по команде может не быть брандмауэра на своем ноутбуке.
Исправить очень просто: просто добавьте 127.0.0.1: впереди. Так, например, 127.0.0.1:8080:8080. Это просто указывает докеру, чтобы он открывал порт только для петлевого сетевого интерфейса и ничего больше.
#docker Открыть/Комментировать

2021-04-06 08:00:35 You’re using docker-compose wrong

Такой заголовок я увидел в блоге Earthly. Мне стало интересно какие же "грехи" мы совершаем при использовании docker-compose. Сразу скажу писал разработчик, использующий docker-compose локально.
У нас осталось 4 будних дня. Вот и опишем по одному "греху" в день.
Грех 1. Использование сети хоста.
Некоторые разработчики грешат тем что используют не bridge driver, а host driver.
Использование сети хоста означает, что вам необходимо зарезервировать определенные порты для различных микросервисов, которые вы используете. Если вам доведется поднять два стека, которые имеют одинаковые порты - проблема. Если вы хотите создать две версии одного и того же стека - проблема. Вы хотите протестировать поведение определенного сервиса, когда у него несколько реплик?
По умолчанию docker-compose запускает свои контейнеры в отдельной сети с именем имякаталога_default. Так что на самом деле вам не нужно делать ничего особенного, чтобы воспользоваться преимуществами сетей Docker.

Эта сеть сразу дает вам ряд преимуществ:
Эта сеть более изолирована от вашей сети хоста, поэтому маловероятно, что особенности вашего системного окружения приведут к изменению поведения настройки сборки. У вас есть доступ к Интернету, но любые порты, которые вы хотите сделать доступными с хоста, должны быть объявлены с привязкой порта.
Если служба начинает прослушивать 0.0.0.0 (как должны делать контейнеры), то настройка сети хоста откроет этот порт в вашей локальной сети. Если вы используете сеть Docker, она предоставит доступ только к этому порту.
Сервисы смогут общаться, используя их имена в качестве имен хостов. Итак, если у вас есть служба с именем db и в ней есть служба, прослушивающая порт 5432, вы можете получить к ней доступ из любой другой службы через db: 5432. Обычно это более понятно, чем localhost: 5432. А поскольку нет риска конфликта портов localhost, у нас больше шансов избежать ошибок при использовании портов в разных проектах.
Большинство портов не нужно открывать для хоста - это означает, что они не конкурируют за глобальные ресурсы, если вам нужно увеличить количество контейнеров с помощью --scale.
#docker Открыть/Комментировать

2021-04-05 08:05:19 Недавно открыл для себя возможности BuildKit для сборки образов контейнеров.
Если не знакомы, то можно познакомится тут:
https://docs.docker.com/develop/develop-images/build_enhancements/
Субъективно скорость сборки образов увеличилась.
Есть еще пару интересных фич. BuildKit стоит за функцией мультиплатформенной сборки docker buildx и поддерживает возможность параллельного выполнения сборок несколькими рабочими процессами. BuildKit также поддерживает кеширование, различные внешние интерфейсы, более быстрые многоступенчатые сборки и т.п.

А надо то всего запустить:
DOCKER_BUILDKIT=1 docker build .

Или для docker-compose:
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build

Захотелось понять как это работает. Наткнулся на статьи Адама Гордона Белла где он описывает прямую работу с Buildkit и сравнивает сборку докер образов с работой компилятора. Перевел их для вас. Если конечно хотите чуток углубится.

#docker #buildkit

https://habr.com/ru/post/550562/ Открыть/Комментировать

2021-03-26 18:17:57 Документация по Kubernetes на русском! Давно она вообще? Как-то прошляпил. В комментах накидайте где (как) лучше изучать? Как книги по нему? Кто-нибудь читал?
https://kubernetes.io/ru/ Открыть/Комментировать