Для тех, кто занимается обеспечением надежности (reliability) работы своих сервисов следующие метрики точно знакомы:
- MTTF - mean time to failure (среднего времени до отказа)
- MTBF - mean time between failures (среднего времени между отказами)
- MTTD - mean time to detect (когда проблема уже присутствовала, но о ней еще не было известно)
- MTTR - mean time to repair/recover/resolve/response (среднее время, необходимое на восстановление работоспособности системы после получения сигнала о сбое.)

Возвращаясь к тому, что reliability и security вещи не разделимы, то эти же метрики можно совершенно успешно использовать и в security для работы с инцидентами безопасности. Так, на пример, MTTD + MTTR = это общая продолжительность инцидента информационной безопасности.

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

https://github.com/mendhak/docker-http-https-echo
#docker #image #testing #github

​​Перевели для вас статью
20 лучших практик по работе с Docker-файлами

Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.

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

К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.

#docker

🎮 Mortal Kombat на JavaScript.
Не большой репозиторий, который содержит сервер и клиент для работы одного скрина игры Mortal Kombat.

🔗 https://github.com/mgechev/mk.js
🔗 http://mk.mgechev.com/

#game #opensource #javascript #github #repo #mortalkombat #fun

о структуре ansible репозитория (часть 1)

Казалось бы тема не сильно сложная, бери беспрактис от ансибла и работай - никаких проблем. Однакож есть несколько моментов, которые они не учитывают:
1. по любым примерам показывается что, мол, храните плейбуки в корне папки ансибла и всё ок. ну вот вам для примера 3 ямлика, красиво же.
2. кросс-инвентарные переменные. правда, я вроде не плохо гуглю, но на оффдоках не нашел ничего похожего.

В чем же проблема №1? а в том, что когда у вас несколько инвентарей, и вы пишете плейбуки которые по смыслу делают одно и то же но в разных инвентарях, вам их надо либо делать строго одинаковыми и в конечном итоге получать один файл (с возможными доработками в виде условий, которые в обычной жизни нахрен не нужны), либо делать несколько файлов для каждого инвентаря. Оба варианта очевидно в конечном итоге приводят к не очень хорошим результатам. В первом случае - это какая-то не нужная логика, которая усложняет поддержку и использование плейбука, а во втором случае у нас просто множится количество файлов. В моем опыте оказалась ситуация когда у коллег удавалось писать "абсолютный" плейбук для своих задач, но это им просто повезло - если ты пишешь плейбук для тестовой и для продовой инфры, сервера по сути одни и те же и способы ввыкладки сервиса тоже. а значит это по сути один и тот же инвентарь, который разделен логически на тест и прод. А вот мне повезло не так сильно и нужно было писать плейбуки под создание сервиса как на своих железках (которые мы можем приготовить как угодно) так и в облаке, а также на "территории" легасёвой инфраструктуры клиента. В таком случае сами понимате сделать 1 плейбук на всё невозможно. Стали рождаться плейбуки вида rolename_inventory_azaza, rolename_inventory_ololo, rolename_inventory_pururum итп. Ситуацию осложняло то, что не все придерживались практики (я никого не виню - не было никакой договорённости) указывать имя инвентаря в имени плейбука.
В конечном итоге ситуация пришла к тому, что в корневом каталоге у нас оказались порядка 50 плейбуков, вперемешку со служебными файлами - gitlab-ci, Dockerfile, ansible.cfg, ansible-lint итп итп. Лично мне стало уже просто неудобно этим оперировать репозиторием. Не критично, не тяжело или как-то сложно, а именно неудобно. плейбуки перестали помещаться в один столбец в pycharm, а понять из названия сразу к какому инвентарю относится плейбук стало тоже непонятно - нужно было заходить внутрь, смотреть группу по которой катался плейбук, грепать ее по инвентарям... короче гемор! При этом в текущем состоянии репозиторий не то чтобы был плох, нет, им вполне можно было пользоваться, но я понимал, что команда у нас растет, а репозиторию меньше года и что дальше будет только хуже. В итоге назрел план небольшой революции и перекроя репозитория. конечный результат - после истории №2.
#ansible

о структуре ansible репозитория (часть 2)

Проблема №2: кросс инвентарные переменные. А вот это нужно для того чтобы можно было из любого инвентаря воспользоваться нужной общей переменной. Например вы создаете виртуалку и хотите чтобы после ее разворота можно было сразу обратиться по доменному имени. Вы добавляете роль управления днс именами в плейбук... а как авторизоваться? как хороший пацан вы написали универсальную роль и не захардкодили в ней параметр с токеном. Или другой пример - база данных пользователей, если вы катаете их ансиблом (хейтеры, отстаньте), то чтобы катать их на разные инвентари и не дублировать, нужно либо иметь один плейбук который будет только что и делать что настраивать пользователей и вы будете запускать его с лимитами по нужным хостам..... ну, да, звучит ужасно. Либо - хранить где-то снаружи ямл с ключами и хешами юзеров. Общие ссл сертификаты. адрес консула. Ну и итд итп, это много где используется. С самого начала такой файл был организован как group_vars/all.yml в корне ансибла. По сути этой бы проблемы не было, если бы не способ решения первого пункта. Для справки как это вообще работало: запускаемый плейбук читает свою директорию. и у него нет никаких проблем залезть в соседнюю с ним папку group_vars и забрать all.yaml а потом сходить в inventory/i_name/ и там прочитать group_vars, host_vars... и так мы получали все нужные переменные при запуске....

А теперь к решению. Для того чтобы сделать красиво я рассмотрел вариант убрать все плейбуки по инвентарям в папку playbooks/i_name. Сказано - сделано. и в этот момент мгновенно перестали работать роли и кросс-инвентарные переменные. Решение вопроса было осуществлено с помощью симлинка. т.е. мы взяли и слинковали в каждом инвентаре кросс-инвентарный файл с переменными. а в ansible.cfg нужно добавить вот эти строки:

[defaults]
roles_path = roles:~/.ansible/roles:/etc/ansible/roles

добавление ~/.ansible/roles нужно для того чтобы подцеплялись galaxy роли.
А конечная структура вышла вот такой:

.
├── inventories
│   ├── global.yml
│   ├── inventory1
│   │   ├── group_vars
│   │   │   ├── all
│   │   │   │   ├── global.yml -> ../../../global.yml
│   │   │   │   └── local.yml
│   │   │   ├── group1.yml
│   │   │   ├── ...
│   │   │   └── groupN.yml
│   │   ├── host_vars
│   │   │   ├── host1.yml
│   │   │   ├── ...
│   │   │   └── hostN.yml
│   │   └── hosts
│   └── inventory2
│       ├── group_vars
│       │   ├── all
│       │   │   ├── global.yml -> ../../../global.yml
│       │   │   └── local.yml
│       │   ├── group1.yml
│       │   ├── ...
│       │   └── groupN.yml
│       ├── host_vars
│       │   ├── host1.yml
│       │   ├── ...
│       │   └── hostN.yml
│       └── hosts
├── playbooks
│   ├── inventory1
│   │   ├── play1.yml
│   │   ├── ...
│   │   └── playN.yml
│   └── inventory2
│       ├── play1.yml
│       ├── ...
│       └── playN.yml
├── roles
│   ├── role1
│   ├── ...
│   └── roleN
├── ansible.cfg
├── tabpy.yml
├── test.yaml
├── wireguard.yml
└── zookeeper.yml

Запуск плейбука осуществляется из директории с ансиблом такой командой:

ansible-playbook -i inventories/inventory1/hosts playbooks/inventory1/play1.yml -bD [--tags, ...]

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

Остается до сих пор проблема того, что в нашем кросс-инвентарном файле может быть довольно много переменных. На текущий момент в качестве решения я думаю о том чтобы сделать symlink кросс-платформенных переменных не на файл global.yml, а на директорию, all -> all. в директори можно хранить множество разделенных по смыслу файлов и все они будут подсасываться во время работы. а файл специфичных для инвентаря переменных вынести по классике в group_vars/all.yml. Но это - тема для будущей революции =)

#ansible

https://www.redhat.com/sysadmin/configure-gmail-using-ansible
#ansible #gmail

​Spaghetti — это интерактивный веб-инструмент, который помогает понять зависимости программы Go, а также изучить и оценить различные возможные меры по устранению зависимостей.

Он отображает полные зависимости исходных пакетов, организованные в виде дерева на основе структуры каталогов пространства имен пакет / модуль.

https://proglib.io/w/23bb0ab8

https://m.habr.com/ru/post/553000/
#linux #cli #tools

https://github.com/jetstack/version-checker
#k8s #kubernetes #github #checker

https://dustinspecker.com/posts/iptables-how-kubernetes-services-direct-traffic-to-pods/
#k8s #kubernetes #iptables

https://medium.com/@kosta709/kubernetes-by-kubeadm-config-yamls-94e2ee11244
#k8s #kubernetes #bootstrap #kubeadm

🔩 OSBuild Composer.

Сборный пост о том, где можно поближе познакомиться с OSBuild Composer - инструментом для создания собственных образов виртуальных машин.

- О том, что такое OSBuild, и какие проекты являются его частью: https://www.osbuild.org/documentation/

- OSBuild Composer Github: https://github.com/osbuild/osbuild-composer

- Cockpit в качестве фронтенда для OSBuild Composer: https://github.com/osbuild/cockpit-composer

- CLI утилита: https://weldr.io/lorax/composer-cli.html

- Create your own Fedora image & push it to cloud: https://www.youtube.com/watch?v=6GIwIRNl6x8

- Build AWS images with Image Builder: https://major.io/2020/06/19/build-aws-images-with-imagebuilder/

#osbuild #cockpit

https://medium.com/ibm-cloud/diving-into-kubernetes-mutatingadmissionwebhook-6ef3c5695f74
#k8s #kubernetes #admission #webhook

https://maelvls.dev/mitmproxy-kubectl/
#k8s #kubernetes #kubectl #mitm #proxy

https://habr.com/ru/post/553908/
#ansible #module

https://medium.com/searce/argocd-gitops-continuous-delivery-approach-on-google-kubernetes-engine-2a6b3f6813c0
#k8s #kubernetes #argocd #gitops

https://threader.app/thread/1385570287983501316
#ui #os #twitter #thread