Forwarded from Mops DevOps
Перевели для вас статью
20 лучших практик по работе с Docker-файлами
Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.
Если вы знакомы с контейнеризованными приложениями и микросервисами, то скорее всего понимаете, что хотя ваши сервисы "микро", но поиск уязвимостей и устранение проблем с безопасностью способен затруднить управление вашими сервисами, уже с приставкой "макро".
К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.
#docker
20 лучших практик по работе с Docker-файлами
Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.
Если вы знакомы с контейнеризованными приложениями и микросервисами, то скорее всего понимаете, что хотя ваши сервисы "микро", но поиск уязвимостей и устранение проблем с безопасностью способен затруднить управление вашими сервисами, уже с приставкой "макро".
К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.
#docker
Forwarded from 🇺🇦 Math.random(): javascript community
This media is not supported in your browser
VIEW IN TELEGRAM
🎮 Mortal Kombat на JavaScript.
Не большой репозиторий, который содержит сервер и клиент для работы одного скрина игры Mortal Kombat.
🔗 https://github.com/mgechev/mk.js
🔗 http://mk.mgechev.com/
#game #opensource #javascript #github #repo #mortalkombat #fun
Не большой репозиторий, который содержит сервер и клиент для работы одного скрина игры Mortal Kombat.
🔗 https://github.com/mgechev/mk.js
🔗 http://mk.mgechev.com/
#game #opensource #javascript #github #repo #mortalkombat #fun
Forwarded from Админим с Буквой (bykva)
о структуре 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
Казалось бы тема не сильно сложная, бери беспрактис от ансибла и работай - никаких проблем. Однакож есть несколько моментов, которые они не учитывают:
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
Forwarded from Админим с Буквой (bykva)
о структуре ansible репозитория (часть 2)
Проблема №2: кросс инвентарные переменные. А вот это нужно для того чтобы можно было из любого инвентаря воспользоваться нужной общей переменной. Например вы создаете виртуалку и хотите чтобы после ее разворота можно было сразу обратиться по доменному имени. Вы добавляете роль управления днс именами в плейбук... а как авторизоваться? как хороший пацан вы написали универсальную роль и не захардкодили в ней параметр с токеном. Или другой пример - база данных пользователей, если вы катаете их ансиблом (хейтеры, отстаньте), то чтобы катать их на разные инвентари и не дублировать, нужно либо иметь один плейбук который будет только что и делать что настраивать пользователей и вы будете запускать его с лимитами по нужным хостам..... ну, да, звучит ужасно. Либо - хранить где-то снаружи ямл с ключами и хешами юзеров. Общие ссл сертификаты. адрес консула. Ну и итд итп, это много где используется. С самого начала такой файл был организован как group_vars/all.yml в корне ансибла. По сути этой бы проблемы не было, если бы не способ решения первого пункта. Для справки как это вообще работало: запускаемый плейбук читает свою директорию. и у него нет никаких проблем залезть в соседнюю с ним папку group_vars и забрать all.yaml а потом сходить в inventory/i_name/ и там прочитать group_vars, host_vars... и так мы получали все нужные переменные при запуске....
А теперь к решению. Для того чтобы сделать красиво я рассмотрел вариант убрать все плейбуки по инвентарям в папку playbooks/i_name. Сказано - сделано. и в этот момент мгновенно перестали работать роли и кросс-инвентарные переменные. Решение вопроса было осуществлено с помощью симлинка. т.е. мы взяли и слинковали в каждом инвентаре кросс-инвентарный файл с переменными. а в ansible.cfg нужно добавить вот эти строки:
А конечная структура вышла вот такой:
Остается до сих пор проблема того, что в нашем кросс-инвентарном файле может быть довольно много переменных. На текущий момент в качестве решения я думаю о том чтобы сделать symlink кросс-платформенных переменных не на файл global.yml, а на директорию, all -> all. в директори можно хранить множество разделенных по смыслу файлов и все они будут подсасываться во время работы. а файл специфичных для инвентаря переменных вынести по классике в group_vars/all.yml. Но это - тема для будущей революции =)
#ansible
Проблема №2: кросс инвентарные переменные. А вот это нужно для того чтобы можно было из любого инвентаря воспользоваться нужной общей переменной. Например вы создаете виртуалку и хотите чтобы после ее разворота можно было сразу обратиться по доменному имени. Вы добавляете роль управления днс именами в плейбук... а как авторизоваться? как хороший пацан вы написали универсальную роль и не захардкодили в ней параметр с токеном. Или другой пример - база данных пользователей, если вы катаете их ансиблом (хейтеры, отстаньте), то чтобы катать их на разные инвентари и не дублировать, нужно либо иметь один плейбук который будет только что и делать что настраивать пользователей и вы будете запускать его с лимитами по нужным хостам..... ну, да, звучит ужасно. Либо - хранить где-то снаружи ямл с ключами и хешами юзеров. Общие ссл сертификаты. адрес консула. Ну и итд итп, это много где используется. С самого начала такой файл был организован как group_vars/all.yml в корне ансибла. По сути этой бы проблемы не было, если бы не способ решения первого пункта. Для справки как это вообще работало: запускаемый плейбук читает свою директорию. и у него нет никаких проблем залезть в соседнюю с ним папку group_vars и забрать all.yaml а потом сходить в inventory/i_name/ и там прочитать group_vars, host_vars... и так мы получали все нужные переменные при запуске....
А теперь к решению. Для того чтобы сделать красиво я рассмотрел вариант убрать все плейбуки по инвентарям в папку playbooks/i_name. Сказано - сделано. и в этот момент мгновенно перестали работать роли и кросс-инвентарные переменные. Решение вопроса было осуществлено с помощью симлинка. т.е. мы взяли и слинковали в каждом инвентаре кросс-инвентарный файл с переменными. а в ansible.cfg нужно добавить вот эти строки:
[defaults]добавление ~/.ansible/roles нужно для того чтобы подцеплялись galaxy роли.
roles_path = roles:~/.ansible/roles:/etc/ansible/roles
А конечная структура вышла вот такой:
.Запуск плейбука осуществляется из директории с ансиблом такой командой:
├── 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
Forwarded from Библиотека Go разработчика | Golang
Spaghetti — это интерактивный веб-инструмент, который помогает понять зависимости программы Go, а также изучить и оценить различные возможные меры по устранению зависимостей.
Он отображает полные зависимости исходных пакетов, организованные в виде дерева на основе структуры каталогов пространства имен пакет / модуль.
https://proglib.io/w/23bb0ab8
Он отображает полные зависимости исходных пакетов, организованные в виде дерева на основе структуры каталогов пространства имен пакет / модуль.
https://proglib.io/w/23bb0ab8
https://dustinspecker.com/posts/iptables-how-kubernetes-services-direct-traffic-to-pods/
#k8s #kubernetes #iptables
#k8s #kubernetes #iptables
Dustin Specker
iptables: How Kubernetes Services Direct Traffic to Pods
This is the third part of a series on Docker and Kubernetes networking. We’ll be tackling how Kubernetes’s kube-proxy component uses iptables to direct service traffic to pods randomly. We’ll focus on the ClusterIP type of Kubernetes services.
The goal of…
The goal of…
Forwarded from Записки админа
🔩 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
Сборный пост о том, где можно поближе познакомиться с 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
#k8s #kubernetes #admission #webhook
Medium
Diving into Kubernetes MutatingAdmissionWebhook
Update: In the latest source code repository, I replaced the webhook server certificate created by the CertificateSigningRequest API and CA…
https://medium.com/searce/argocd-gitops-continuous-delivery-approach-on-google-kubernetes-engine-2a6b3f6813c0
#k8s #kubernetes #argocd #gitops
#k8s #kubernetes #argocd #gitops
Medium
ArgoCD : GitOps Continuous Delivery Approach On Google Kubernetes Engine
If you are getting started with ArgoCD, Its Installation, Working, RollOuts, Deployments Strategies(BlueGreen, Canary) with Demo then you…
Forwarded from Технологический Болт Генона
Container Networking Is Simple!
> Updated: March 20, 2021
https://iximiuz.com/en/posts/container-networking-is-simple/
> Updated: March 20, 2021
https://iximiuz.com/en/posts/container-networking-is-simple/