Барабанная дробь... 🥁 Подвели итоги розыгрыша! 🎉

Условия были не самые простые, большое спасибо всем, кто ответил на вопросы и поделился мнением о нашем канале.

Это не последний конкурс, обязательно придумаем что-нибудь еще, ну а пока — будем делать DevOps FM лучше 😎

И, разумеется, поздравляем победителя!

@Mik9524, вы выиграли футболку «Злой DevOps» 🥳! Носите с удовольствием! :) В ближайшее время вам напишет администратор канала.

Всем DevOps! 🖖

Мы любим читать истории фанатов технологий и сегодня хотим поделиться рассказом «Why and how I use k8s for my personal stuff (and love it)».

🗣️ Я один из тех чокнутых, которые любят Kubernetes. Мне он так нравится, что в настоящее время он поддерживает множество моих личных штук и хобби-проектов. Итак, вместо привычных «k8s раздут», «k8s — это излишество» или «почему вам не нужен k8s», давайте поговорим о том, почему k8s на самом деле отлично подходит для личных целей, и почему вам, возможно, также стоит подумать об его использовании.

Может быть, вы тоже пользуетесь k8s для личных проектов? Расскажите :)

#статьи

Бесплатный видеокурс по SRE

Как раз можно на выходных посмотреть (хотя, конечно, на выходных лучше отдыхать 🏖)

Курс выпустили Тинькофф Образование буквально на днях. 14 видео, +- по часу. Рассказываются основные темы, начиная от "Что такое SRE" до "Как тестировать в продакшен". Хороший способ прокачать экспертизу, тем более всё на русском языке.

Желаем отличной пятницы и классных выходных! 🔥

#видео

Рассказываем про два open-source инструмента с похожими названиями 😎

▪️Kube-Scan — open-source утилита для оценки риска кластера среды оркестрации, в основе которого лежит Kubernetes.

Для расчета уровня риска используется модель Octarine Kubernetes Common Configuration Scoring System (KCCSS). Она похожа на Common Vulnerability Scoring System (CVSS), стандарт для расчета уровня риска по уязвимостям, только вместо акцента на уязвимости делается акцент на конфигурацию и параметры безопасности в ней.

▪️KubiScan — open-source утилита, которая собирает информацию о том, где и какие расширенные привилегии используются на уровне кластера Kubernetes, если в основе контроля доступа лежит RBAC.

Инструмент был опубликован в рамках исследования «Защита кластеров Kubernetes путем устранения рискованных разрешений»

#open_source

Sber OPS Meetup: удобство, функциональность, надежность

Бесплатный митап — отличная возможность пообщаться с единомышленниками и обсудить актуальные темы ИТ-сопровождения: Kubernetes Governance as a Code, dev/staging/testing-ветки, рабочее пространство администратора и техподдержку для сотрудников.

🗓 Когда? 10 июля 18:00 (МСК, GMT+3)

🌐 Онлайн — трансляция на сайте
📍 Офлайн — офис Сбера по адресу: Москва, Кутузовский проспект, 32, корпус Г

Что в программе? Доклады!

▪️«Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке»

▪️«Разделение на dev/master-ветки при деплое на стенды: паттерн или антипаттерн?»

▪️«Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок»

▪️«Как мы в Сбере предоставляем техническую поддержку сотрудникам»

➡️ Для участия в онлайне или офлайне нужно зарегистрироваться.

Сегодня целых два повода, чтобы немного расслабиться: маленькая пятница 🥳 и день трудоголика 😭

Поэтому предлагаем посмотреть познавательную документалку «Kubernetes: The Documentary». Фильм в двух частях (раз, два), на английском, но есть русские субтитры.

Как создавался Kubernetes? Почему он стал open-source и что сделало его, по сути, стандартом оркестрации? Об этом фильм :) Особенно интересно, что всю историю рассказывают люди, принимавшие непосредственное участие в разработке Kubernetes: инженеры из Google, Red Hat, Twitter и других компаний.

Всем DevOps! 🖖

#видео

It's Wednesday, my friends! 🆘

Пособирали разных статей, делимся подборкой.

▪️Гайд «GitHub to GitLab migration the easy way» — как перейти с GitHub на GitLab, используя функцию импорта проектов. Рассматривается и ручная миграция GitHub Actions в GitLab pipelines. Есть видео :)

▪️Статья «How to delegate tasks as a senior/lead engineer?» — как эффективно делегировать задачи членам команды. Забавные аналогии и жизненные ситуации прилагаются.

▪️Статья «Как я стал девопсом в городе, в котором есть только завод» — всегда интересно почитать про путь в профессию, особенно, когда у автора в моногороде два пути: на завод или в IT.

▪️Статья «Монолит или микросервисы — это не вопрос технологических предпочтений, это про time-to-market» — из названия все понятно, автор рассматривает вопрос монолит vs микросервисы через призму команд, их взаимодействия и интересов бизнеса.

(кстати, делали подборку всякого интересного на эту тему — вот здесь)

Всем DevOps! 🖖

#статьи

В эфире — новости!

▪️На 15 августа 2023 года запланирован релиз Kubernetes 1.28. Ожидается 59 новых улучшений , из которых 33 — alpha, 19 — beta и 15 — stable. Подробное описание доступно в release notes (пока черновик).

▪️Состоялся релиз KubeVirt 1.0.0. Подробности — в release notes.

❓KubeVirt — это надстройка по управлению ВМ для K8s. Его цель — обеспечить общую основу для решений виртуализации поверх K8s. С помощью KubeVirt можно управлять ВМ как ресурсом K8s, подобно подам.

▪️В пятницу, 7 июля 2023 года, в инфраструктуре Jenkins произошел серьезный сбой с 11:05 UTC до 15:25 UTC, Jenkins выпустили Postmortem об этом инциденте.

*️⃣Писали про Postmortem здесь :)

▪️Компания Yandex Cloud проинформировала пользователей об ограничении доступности Managed service for Elasticsearch.

Действующие пользователи смогут работать с существующими кластерами и создавать новые до апреля 2024 года. Пользователи, которые пока не работали с Elasticsearch в облаке, не смогут создать кластеры сервиса с 20 июля 2023 года.

▪️Istio получили статус CNCF Graduated project. Первоначально Istio был разработан Google и IBM и построен на основе проекта Envoy от Lyft. В настоящее время в проекте участвуют более 16 компаний, в том числе многие крупнейшие поставщики сетевых услуг и облачные организации по всему миру. Istio — третий по активности проект CNCF по количеству открытых и смерженных PR.

❓Istio — инструмент конфигурации service mesh

#новости

Всем DevOps! 🖖

Начнем неделю с полезных советов: Три простых приема для уменьшения Docker-образов 💻

Образы, которые используют одни и те же слои и весят меньше — быстрее переносятся и деплоятся.
Но как контролировать размер, когда каждое выполнение оператора RUN создает новый слой? Плюс, еще нужны промежуточные артефакты до создания самого образа...

1️⃣ Объединяем несколько слоев в один с помощью поэтапной сборки Docker-образов

Когда Git-репозиторий разрастается, можно просто свести всю историю изменений в один commit и забыть о нем. Оказалось, что нечто подобное можно реализовать и в Docker — посредством поэтапной сборки.

Давайте создадим контейнер Node.js.

Начнем с index.js:

const express = require('express')
const app = express()
app.get('/', (req, res) => res.send('Hello World!'))
app.listen(3000, () => {
 console.log(Example app listening on port 3000!)
})

и package.json:

{
 "name": "hello-world",
 "version": "1.0.0",
 "main": "index.js",
 "dependencies": {
   "express": "^4.16.2"
 },
 "noscripts": {
   "start": "node index.js"
 }
}

Упакуем приложение со следующим Dockerfile:

FROM node:8
EXPOSE 3000
WORKDIR /app
COPY package.json index.js ./
RUN npm install
CMD ["npm", "start"]

Создадим образ:

$ docker build -t node-vanilla .

Проверим, что все работает:

$ docker run -p 3000:3000 -ti --rm --init node-vanilla

Теперь можно пройти по ссылке: http://localhost:3000 и увидеть там «Hello World!».

В Dockerfile теперь у нас есть операторы COPY и RUN, так что фиксируем увеличение как минимум на два слоя, по сравнению с исходным образом:

$ docker history node-vanilla

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

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]

Первая часть Dockerfile создает три слоя. Затем слои объединяются и копируются на второй и заключительный этапы. Сверху в образ добавляются еще два слоя. В итоге имеем три слоя.

Давайте пробовать. Сначала создаем контейнер:

$ docker build -t node-multi-stage .

Проверяем историю:

$ docker history node-multi-stage

Смотрим, изменился ли размер файла:

$ docker images | grep node-
node-multi-stage   331b81a245b1   678MB
node-vanilla       075d229d3f48   679MB

Да, он стал меньше, но пока не значительно. Есть способы уменьшить его сильнее.

*️⃣2 и 3 приемы будут чуть позже :)

#лонгрид

2️⃣ Сносим все лишнее из контейнера с помощью distroless

Текущий образ предоставляет нам Node.js, yarn, npm, bash и много других полезных бинарников. Также, он создан на базе Ubuntu. Таким образом, развернув его, мы получаем полноценную операционную систему со множеством полезных бинарников и утилит.

При этом они не нужны нам для запуска контейнера. Единственная нужная зависимость — это Node.js.

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

Таким образом, мы можем вынести из него все, кроме Node.js.

Но как?

В Google уже пришли к подобному решению — GoogleCloudPlatform/distroless.

Описание к репозиторию гласит:

Distroless-образы содержат только приложение и зависимости для его работы. Там нет менеджеров пакетов, shell'ов и других программ, которые обычно есть в стандартном дистрибутиве Linux.

Это то, что нужно!

Запускаем Dockerfile, чтобы получить новый образ:

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM gcr.io/distroless/nodejs
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]

Собираем образ как обычно:

$ docker build -t node-distroless .

Приложение должно нормально заработать. Чтобы проверить, запускаем контейнер:

$ docker run -p 3000:3000 -ti --rm --init node-distroless

И идем на http://localhost:3000. Стал ли образ легче без лишних бинарников?

$ docker images | grep node-distroless
node-distroless   7b4db3b7f1e5   76.7MB

Еще как! Теперь он весит всего 76,7 МБ, на целых 600 Мб меньше!

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

$ docker exec -ti <insert_docker_id> bash

Подключение к работающему контейнеру и запуск bash очень похоже на создание SSH-сессии.

Но поскольку distroless — это урезанная версия исходной операционной системы, там нет ни дополнительных бинарников, ни, собственно, shell!

Как подключиться к запущенному контейнеру, если нет shell?

Самое интересное, что никак.

Это не очень хорошо, так как исполнять в контейнере можно только бинарники. И единственный, который можно запустить — это Node.js:

$ docker exec -ti <insert_docker_id> node

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

Тут надо бы оговориться, что подключать и отлаживать контейнеры на prod-окружении не стоит. Лучше положиться на правильно настроенные системы логирования и мониторинга.

Но что, если нам-таки нужен дебаггинг, и при этом мы хотим, чтобы docker-образ имел наименьший размер?

#лонгрид

3️⃣ Уменьшаем базовые образы с помощью Alpine

Можно заменить distroless на Alpine-образ.

Alpine Linux — это ориентированный на безопасность, легкий дистрибутив на основе musl libc и busybox. Но не будем верить на слово, а лучше проверим.

Запускаем Dockerfile с использованием node:8-alpine:

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8-alpine
COPY --from=build /app /
EXPOSE 3000
CMD ["npm", "start"]

Создаем образ:

$ docker build -t node-alpine .

Проверяем размер:

$ docker images | grep node-alpine
node-alpine   aa1f85f8e724   69.7MB

На выходе имеем 69.7MB — это даже меньше, чем distroless-образ.

Проверим, можно ли подключиться к работающему контейнеру (в случае с distrolles-образом мы не могли этого сделать).

Запускаем контейнер:

$ docker run -p 3000:3000 -ti --rm --init node-alpine
Example app listening on port 3000!

И подключаемся:

$ docker exec -ti 9d8e97e307d7 bash
OCI runtime exec failed: exec failed: container_linux.go:296: 
starting container process caused "exec: \"bash\": 
executable file not found in $PATH": unknown

Неудачно. Но, возможно, у контейнера есть sh'ell…:

$ docker exec -ti 9d8e97e307d7 sh / #

Отлично! У нас получилось подключиться к контейнеру, и при этом его образ имеет ещё и меньший размер. Но и тут не обошлось без нюансов.

Alpine-образы основаны на muslc — альтернативной стандартной библиотеке для C. В то время, как большинство Linux-дистрибутивов, таких как Ubuntu, Debian и CentOS, основаны на glibc. Считается, что обе эти библиотеки предоставляют одинаковый интерфейс для работы с ядром.

Однако у них разные цели: glibc является наиболее распространенной и быстрой, muslc же занимает меньше места и написана с уклоном в безопасность. Когда приложение компилируется, как правило, оно компилируется под какую-то определенную библиотеку C. Если потребуется использовать его с другой библиотекой, придется перекомпилировать.

Другими словами, сборка контейнеров на Alpine-образах может привести к неожиданному развитию событий, поскольку используемая в ней стандартная библиотека C отличается. Разница будет заметна при работе с прекомпилируемыми бинарниками, такими как расширения Node.js для C++.

Например, готовый пакет PhantomJS не работает на Alpine.

Так какой же базовый образ выбрать?

Alpine, distroless или ванильный образ — решать, конечно, лучше по ситуации.

Если имеем дело с prod-ом и важна безопасность, возможно, наиболее уместным будет distroless.

Каждый бинарник, добавленный к Docker-образу, добавляет определенный риск к стабильности всего приложения. Этот риск можно уменьшить, имея только один бинарник, установленный в контейнере.

Например, если злоумышленник смог найти уязвимость в приложении, запущенном на базе distroless-образа, он не сможет запустить в контейнере shell, потому что его там нет!

Если же по каким-то причинам размер docker-образа для вас крайне важен, определенно стоит присмотреться к образам на основе Alpine.

Они реально маленькие, но, правда, ценой совместимости. Alpine использует немного другую стандартную библиотеку C — muslc, так что иногда будут всплывать какие-то проблемы. С примерами можно ознакомиться по ссылкам: https://github.com/grpc/grpc/issues/8528 и https://github.com/grpc/grpc/issues/6126.

Ванильные же образы идеально подойдут для тестирования и разработки.

Да, они большие, но зато максимально похожи на полноценную машину с установленной Ubuntu. Кроме того, доступны все бинарники в ОС.

#лонгрид