💻 Не так давно Kubernetes обновился до версии 1.29: Mandala

Самые значимые фичи, перешедшие в статус стабильных:

🔵Режим доступа для особо конфиденциальных данных. Если вы создаете под с PVC, который использует режим доступа ReadWriteOncePod, Kubernetes гарантирует, что ни один другой модуль во всем кластере не сможет считать или записать в PV данные.

🔵KMS версии 2. Теперь она обеспечивает многочисленные улучшения производительности, ротацию ключей, проверку работоспособности статуса и его мониторинг.

🔵NodeExpandSecret в GA. Эта функция добавляет Node Expand Secret к источникам постоянных томов SCSI и позволяет клиентам CSI отправлять его как часть запросов NodeExpandVolume драйверу CSI.

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

@DevOPSitsec

⚡️ Groq — это чат-бот, основанный на Mixtral, способен генерировать точные ответы за доли секунды!

Скорость генерации текста у этого аналога ChatGPT впечатляет:
500 токенов в секунду (!) — просто невероятно

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

Пообщаться с Groq (в РФ не работает, use VPN)

@DevOPSitsec

🔤Как включить доступ к CUDA внутри контейнера Podman

Как полагается, и на сей раз официальные инструкции не работают. В общем, нужно так.

1. Ставим Podman, если нет — dnf install podman

2. Подключаем репу и ставим Nvidia container toolkit.
wget https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
sudo cp nvidia-container-toolkit.repo /etc/yum.repos.d/
sudo dnf update
sudo dnf nvidia-container-toolkit

В процессе dnf ругнётся на отсутствующие сертификаты, предложит скачать.

3. Вводим в Podman параметры аккаунта на DockerHub — podman login docker.io А дальше отвечаем на вопросы.

4. Скачиваем образ заранее. Заковырка в том, что Podman может скачать только образ, которому указана полная версия. И никаких latest. Варианты смотреть на Docker Hub. Например, podman pull nvidia/cuda:12.3.1-runtime-rockylinux9

5. Создаём конфиг Container Device Interface
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

6. Его есть смысл проверить (от юзера!):
nvidia-ctk cdi list

7. Ну и наконец запускаем и проверяем. Должна вылезти табличка с параметрами видеокарты, это значит что всё работает.
podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable nvidia/cuda:12.3.1-runtime-rockylinux9 nvidia-smi

Вот теперь на основании этого образа можно клепать свои контейнеры.

P.S. Проверено на Nobara, это кусок Федоры, но должно работать так же на всей RedHat.

@DevOPSitsec

💻 Open-source инструменты в помощь DevOps специалисту

𝗧𝗿𝗶𝘃𝘆
— это инструмент от Aqua Security для поиска уязвимостей и ошибок неправильных настроек
🖥 trivy

𝗦𝗲𝗮𝗹𝗲𝗱 𝗦𝗲𝗰𝗿𝗲𝘁𝘀
— интегрируется в Kubernetes, позволяя расшифровывать конфиденциальные данные только контроллеру Kubernetes, запущенному в Kubernetes, и больше никому. Контроллер расшифрует данные и создаст собственные секреты K8s, которые будут надежно сохранены.
🖥 sealed-secrets

𝗧𝗲𝗿𝗿𝗮𝘀𝗰𝗮𝗻
— статический опенсорсный анализатор кода, созданный на основе OPA. Terrascan может проявлять уязвимость безопасности и нарушение нормативных требований. Инструмент имеет более 500 политик, которые помогают обеспечить надежность для различных программ
🖥 terrascan

𝗞𝘂𝗯𝗲𝗔𝗿𝗺𝗼𝗿
— это система обеспечения безопасности среды выполнения контейнеров, которая ограничивает поведение (например, выполнение процессов, доступ к файлам, сетевые операции и использование ресурсов) контейнеров на системном уровне.
🖥 KubeArmor

Пользуйтесь)

@Golang_google

🛠 Архитектура CI/CD с использованием конвейеров Azure Pipelines

Высокоуровневый рабочий процесс DevOps для развертывания изменений в приложениях в средах staging и production в Azure

Данные проходят через такие этапы:

1. Конвейер PR.
Запрос на извлечение (PR) в Azure Repos Git запускает конвейер PR. Этот конвейер выполняет быстрые проверки качества. Эти проверки должны включать:
- Создание кода, требующего извлечения зависимостей из системы управления зависимостями
- Использование инструментов для анализа кода, таких как статический анализ кода и линтинг
- Модульные тесты

2. Конвейер CI.
Слияние с Azure Repos Git запускает конвейер CI. Этот конвейер выполняет те же проверки, что и PR-конвейер, но с некоторыми важными дополнениями. Конвейер CI выполняет интеграционные тесты. Эти интеграционные тесты не должны требовать развертывания решения, поскольку артефакты сборки еще не созданы.

3. Триггер конвейера CD.
Публикация артефактов запускает конвейер CD.

4. Выпуск CD в промежуточную среду.
Конвейер CD загружает артефакты сборки, созданные в конвейере CI, и развертывает решение в промежуточной среде. Затем конвейер запускает приемочные тесты в промежуточной среде для проверки развертывания.

5. Выпуск CD в продакшен

6. Мониторинг.
Azure Monitor собирает данные наблюдения, такие как журналы и метрики, чтобы оператор мог анализировать данные о работоспособности, производительности и использовании.

🔗 Подробнее почитать можно тут

@DevOPSitsec

📌Всё про сортировку веток Git

Запустив git branch в репозитории, вы обычно получаете список веток в алфавитном порядке. Это может раздражать, когда у вас много веток (если только у вас нет очень жесткой системы именования по номеру тикета или чего-то подобного).
⏩Не проблема, это можно изменить. Выполните в вашем репозитории следующую команду:

git branch --sort=-committerdate

Это отсортирует все ваши ветки по дате их последнего коммита

Для сортировки доступны такие опции:
- authordate
- committerdate
- creatordate
- objectsize
- taggerdate

⏩Кроме того, если хотите всегда сортировать по одному из этих параметров, можно установить это в настройках:

git config --global branch.sort -committerdate

⏩Также можно задать псевдоним:

git config --global alias.brcd "branch --sort=-committerdate".

Подробнее о работе с ветками можно почитать тут, ловите ссылки:
📎 Ветвление Git с примерами из реальной жизни
📎 Как удалить ветку в Git
📎 Как переименовать локальную ветку в Git

@DevOPSitsec

🔄Как упростить работу с YAML-файлами

YAML — популярный язык для конфигурационных файлов, широко используемый DevOps в подходе «Инфраструктура как Код» (IaC).
Давайте рассмотрим несколько советов, которые помогут упростить работу с yml-файлами.


Используйте специализированные редакторы и плагины
Очевидный совет, но мало ли; работа с YAML в правильной среде даёт:
🔘подсветку синтаксиса
🔘автодополнение кода
🔘проверку отступов
🔘сниппеты (шаблоны кода)

Популярные плагины: YAML Support для VS Code, yaml-mode для Emacs, drawspaces для Gedit.


Генерируйте YAML из кода
Ручное написание сложных конфигураций на YAML не так приятно. Проще сначала определить нужную структуру данных в виде словарей и массивов в том же Python, а затем сгенерировать из нее YAML.

Есть такая структура:

data = {
  "server": {
    "port": 8000,
    "enabled": true
  },
  "clients": [
    {"name": "Client1", "address": "192.168.1.100"}, 
    {"name": "Client2", "address": "192.168.1.101"}
  ]
}

С помощью PyYAML легко конвертируем в YAML-файл:

import yaml
with open('config.yaml','w') as f:
  f.write(yaml.dump(data))

Получаем:

  
server:
  port: 8000
  enabled: true
clients:
- address: 192.168.1.100
  name: Client1  
- address: 192.168.1.101
  name: Client2

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

Например, при развертывании микросервисов в Kubernetes удобно иметь шаблон манифеста deployment.yaml:

apiVersion: apps/v1
kind: Deployment 
metadata:
  name:  <service_name> 
  labels:  
    app: <service_name>
spec:
  replicas: 3
  template:
    metadata: 
      labels:
        app: <service_name>                
    spec:
      containers:
      - name: <service_name> 
        image: <image>:<tag>
        ports:
        - containerPort: <port> 
---        
apiVersion: v1
kind: Service

▶️ Ещё несколько полезных советов по YAML

@DevOPSitsec