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

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

Как поступить, если данные больше не влезают на один сервер? Существуют 2 классических механизма масштабирования:

DevOps — это не столько профессия, сколько культура и методика. В современной IT-отрасли — это важное связующее звено между командой разработки и командой эксплуатации. В DevOps-культуре можно условно выделить следующие роли:

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

Нередко пользователи сервиса GitLab сталкиваются с проблемой под названием «Ошибка 502». Как правило, она сопровождается следующей фразой: «Whoops, GitLab is taking too much time to respond». Давайте разберём, в чём может быть проблема.

Основная сложность перехода на CI/CD — адаптация подхода, при котором на первом месте у нас находятся процессы, а только на втором — технологии. Следовательно, надо определять новые роли и выстраивать новые процессы, а также находить точки соприкосновения новых и уже существующих процессов. В этом-то и заключается сложность, ведь смещая акцент с «железа» и софта на организационные аспекты работы и людей, многие сталкиваются с серьёзным вызовом.

Контейнеризация обеспечивает нам непрерывную интеграцию и поставку ПО (CI/CD), что соответствует современному подходу DevOps. И правда, упаковав в контейнер программное окружение, мы сможем быстро развернуть микросервис на рабочем сервере, безопасно взаимодействуя с прочими приложениями. И многим хорошо знаком Docker Compose, позволяющий описывать и запускать многоконтейнерные приложения. Но если нам нужно обеспечить действительно сложный порядок запуска огромного количества таких контейнеров (допустим, нескольких тысяч, как это нередко бывает в Big Data-системах), то не обойтись без эффективного средства управления ими – инструмента оркестрации. Как раз в этом и заключается основное назначение Kubernetes.

В этой статье поговорим о последнем уровне из набора по безопасности Kubernetes. Тут уместно ещё раз вспомнить «первую заповедь» докеровода: «Не храните secrets в докер-файлах». Но даже если мы не храним их в докер-images, мы храним их где-нибудь в Kubernetes, что тоже небезопасно.

Все знают про аутентификацию, авторизацию и аудит в Kubernetes. Но нередко возникает вопрос: «Как правильно строить аутентификацию?» Дело в том, что тут есть ряд антипаттернов: