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"
 },
 "scripts": {
   "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. Кроме того, доступны все бинарники в ОС.

#лонгрид

Представляем nxs-data-anonymizer — удобный инструмент для анонимизации баз данных 🔥

И не просто инструмент, а open source инструмент компании Nixys! Поддерживает PostgreSQL (все версии) и MySQL/MariaDB/Percona (все версии).

Решение получилось достаточно гибким и простым в эксплуатации, и строится на следующих основных идеях:

⚙️ Потоковая обработка данных. Не обязательно предварительно готовить и сохранять где-то на диске дамп исходной базы. Инструмент может менять на лету данные, которые ему передаются на stdin. А выдавать всё — на stdout.

⚙️ Значения описываются Go template. То, на что вы хотите заменить нужные вам ячейки в таблице, определяется шаблонами как в Helm, который многим должен быть знаком.

⚙️ Использование условий и данных других ячеек в строке. Фильтры могут быть гибкими и делать те или иные подстановки в зависимости от значений других (или даже себя самого) ячеек в той же строке;

⚙️ Проверка уникальности данных.

Подробно рассказали про инструмент в статье на Хабре! Делитесь вашим мнением в комментариях :)

И, конечно, заходите в репозиторий — пользуйтесь инструментом, ставьте звездочки, оставляйте PR, рассказывайте коллегам 🦾

💻 Ссылка на GitHub

#open_source #статья_Nixys

Мы не договорили! 😁 Недавно делали подборку про Network Policy в Kubernetes, сегодня хочется сделать тематический день и рассказать про управление трафиком в Kubernetes-кластере с Calico.

Поехали! 💻

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

Помимо этого Calico добавляет свою политику GlobalNetworkPolicy. Она позволяет применять набор правил доступа по селектору не только для pod’ов, но и для групп хостов/контейнеров/pod’ов, и контролировать применение мер безопасности для различных цепочек путей трафика с помощью таких параметров, как preDNAT, doNotTrack и applyOnForward.

Задачу по обеспечению базовых принципов безопасности мы условно разделим на две:

1) на подзадачу по настройке взаимодействия между pod’ами

2) на подзадачу по настройке доступа к узлу в целом

Решить первую подзадачу можно при помощи такой сущности Kubernetes как NetworkPolicies и при этом можно расширить функционал данной сущности, если использовать её с api, предоставляемого Calico. Для решения второй подзадачи мы будем использовать сущность GlobalNetworkPolicy. По ходу дела так же будем анализировать детали и начнем с Zero Trust Networking.

Zero Trust Networking

Первое, что стоит учесть при написании сетевых политик, это то, что и Kubernetes, и Calico считают наилучшим подход Zero Trust Networking, то есть по умолчанию запросы из используемой сети всегда считаются враждебными.

Согласно данной концепции существуют следующие требования к контролю доступа:

* Правила применяются ко всем сетевым подключениям (не только к тем, которые пересекают границы защищаемой зоны).
* Идентификация удаленного endpoint всегда основана на нескольких критериях, включая надежные криптографические доказательства идентичности. В частности, идентификаторы сетевого уровня, такие как IP-адрес и порт, сами по себе недостаточны, поскольку могут быть подделаны враждебной сетью.
* Все ожидаемые и разрешенные сетевые подключения явно указаны в белом списке. Любое соединение, явно не занесенное в белый список, отклоняется.
* Трафик от скомпрометированных workload (pod/VM/container) не должен иметь возможности обойти применение сетевых политик.

Во многих Zero Trust Networks также реализуется шифрование всего сетевого трафика. Это не является обязательным требованием (если речь идет не о передаче приватных данных), но для соответствия критериям Zero Trust Networks шифрование должно использоваться для каждого сетевого соединения.

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

Аналогично с HostEndpoint, как только он будет создан, весь трафик к хосту будет запрещен, кроме определенного перечня портов, который останется открытым. Причем, даже если вы создадите политики, которые явно запрещают доступ к этим портам, они останутся открытыми.

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

*️⃣1/6: продолжение следует :)

#лонгрид

Из чего состоит Calico

Кратко рассмотрим основные компоненты Calico. Как вы уже, наверное, поняли, Calico — это не один демон, который запущен на каждом хосте, где он управляет сетью, Calico состоит из нескольких элементов, так же как и Kubernetes. В целом он состоит из трех (иногда четырех) компонентов.

Felix

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

* Управление сетевыми интерфейсами, их создание, проверка их работоспособности и настройка пересылки трафика для управляемых интерфейсов.
* Программирование маршрутизации трафика через FIB (Forwarding Information Base) ядра Linux.
* Программирование ACL на уровне ядра Linux.
* Уведомления о статусе сети, Felix записывает данные о проблемах и ошибках в etcd.

Плагин для оркестратора

В зависимости от того, какой оркестратор вы используйте (например, OpenStack, Kubernetes) Calico предоставляет определенный плагин для наиболее эффективного взаимодействия с оркестратором. В случае Kubernetes — это CNI plugin.

etcd

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

BGP клиент (BIRD)

Calico разворачивает клиент BGP на каждой ноде, на которой размещен Felix. Роль клиента BGP заключается в том, чтобы считывать настройки маршрутизации, которые Felix создает на уровне ядра, и распространять на другие ноды обслуживаемой сети, то есть рассылать на другие клиенты.

BGP повторитель для правил маршрутов (BIRD)

В случае, когда обслуживаемая Calico область достаточно велика при наличии только BGP клиента могут возникнуть проблемы, так как он требует чтобы каждый клиент мог соединиться с каждым клиентом, что может порождать слишком большое количество соединений(N ^ 2). В таких случаях для решения проблемы можно использовать повторитель маршрутов, то есть соответственно настроенный BIRD. Он занимается тем, что, если клиент BGP сообщает ему какую-либо информацию об изменении в маршрутах, он распространяет эту информацию для других BGP-клиентов.

Network Policy

NetworkPolicy, который предоставляет Calico, имеет более читаемый и развернутый синтаксис, чем тот, который предлагает сам Kubernetes.

Ресурс сетевой политики NetworkPolicy представляет собой упорядоченный набор правил, которые применяются к группе endpoints, соответствующих селектору меток (labels).

Простой пример из официальной документации:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-tcp-6379
  namespace: production
spec:
  selector: role == 'database'
  types:
  - Ingress
  - Egress
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: role == 'frontend'
    destination:
      ports:
      - 6379
  egress:
  - action: Allow

Здесь мы разрешаем трафик с подов/контейнеров, у которых есть селектор role == 'frontend' на порт 6379 для доступа к БД.

*️⃣2/6: продолжение следует :)

#лонгрид

Host Endpoint

У каждого хоста (ноды) есть несколько реальных или виртуальных сетевых интерфейсов, с которыми взаимодействует Calico. Чтобы получить возможность применять политики конкретно к определенному интерфейсу необходимо создать для него сущность HostEndpoint. Они могут иметь метки (labels) и эти метки аналогичны меткам для pod’ов, поэтому сетевые политики в равной степени могут применяться и к HostEndpoint, и к endpoints pod’ов.

Предположим, что нам нужно запретить весь входящий трафик из внешней сети, кроме портов 22, 80, 443 на уровне хоста и при этом разрешить весь трафик от других нод кластера. Для этого, для начала, создадим для каждой ноды свой HostEndpoint. К примеру:

apiVersion: projectcalico.org/v3
kind: HostEndpoint
metadata:
  name: node4-ens160
  labels:
    type: production
role: worker
        node: 4
spec:
  interfaceName: ens160
  node: k8s-s4
  expectedIPs:
  - 10.213.0.11
ports:
 - name: http
   port: 80
   protocol: TCP
 - name: https
   port: 443
   protocol: TCP

В данном случае мы добавили также раздел ports, где описали определенные порты и протоколы для взаимодействия с ними. Мы сделали это для того, чтобы обозначить их и дать им названия (http, https), которые в дальнейшем можно использовать в сетевых политиках. interfaceName — название внешнего интерфейса сервера которому соответствует IP-адрес expectedIPs. Указывать порт 22 нет необходимости, так как он разрешен на уровне конфигурации Felix.

Global Network Policy

Теперь, когда почти весь трафик к ноде заблокирован, создадим GlobalNetworkPolicy, которая разрешит весь трафик с других нод кластера, входящий трафик на порты 80/443 и весь исходящий трафик для этого HostEndpoint:

kind: GlobalNetworkPolicy
apiVersion: projectcalico.org/v3
metadata:
  name: allow-s4
spec:
  selector: role==worker
  order: 10
  applyOnForward: true
  types:
  - Egress
  - Ingress
  ingress:
  - action: Allow
    protocol: TCP
    source:
      nets:
            - 10.213.0.0/24
  - action: Allow
    protocol: TCP
    destination:
      ports: [http,https]
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow

В целом, все параметры GlobalNetworkPolicy аналогичны NetworkPolicy и интуитивно понятны. order — очередность применения политики, чем она меньше, тем раньше будет применено правило.

Однако, для GlobalNetworkPolicyесть несколько интересных параметров, которые предоставляют дополнительные возможности для настройки политик, а именно: preDNAT, doNotTrack и applyOnForward, рассматриваемые ниже.

*️⃣3/6: продолжение следует :)

#лонгрид