https://www.docker.com/blog/compiling-containers-dockerfiles-llvm-and-buildkit/
#container #buildkit #docker
#container #buildkit #docker
Docker
Compiling Containers - Dockerfiles, LLVM and BuildKit | Docker
Learn from Docker experts to simplify and advance your app development and management with Docker. Stay up to date on Docker events and new version
https://medium.com/tanker-blog/automating-version-number-updates-what-could-go-wrong-75edd190ee47
#semver #bump
#semver #bump
Medium
Automating version number updates: what could go wrong?
Say you need to update (bump) your software. It’s currently at version 1.2, all the required changes have been merged, and it’s time to…
I'm sorry. I know you thought that validating an email address is simple, but I'm afraid that you're wrong here. It's a bit more complicated than you think. Quite a bit, actually. Allow me to illustrate:
What does an email address look like? For the most part, that's easy, right? We have a username, followed by an @ sign, followed by a domain name and we're done. For example: jschauma@netmeister.org. Simple enough.
Alas, it turns out that it's not that easy. And so to really understand what is valid (even if not necessarily widely accepted) and what is invalid (even if perhaps still accepted by some mail servers), we of course have to go back to the RFCs. We'll start out with RFC5321, and just to be comprehensive, we're strictly looking at the MAIL FROM / RCPT TO SMTP commands, as defined in Section 4.1.2. So let's start:...
https://www.netmeister.org/blog/email.html
#mail #email #validation
What does an email address look like? For the most part, that's easy, right? We have a username, followed by an @ sign, followed by a domain name and we're done. For example: jschauma@netmeister.org. Simple enough.
Alas, it turns out that it's not that easy. And so to really understand what is valid (even if not necessarily widely accepted) and what is invalid (even if perhaps still accepted by some mail servers), we of course have to go back to the RFCs. We'll start out with RFC5321, and just to be comprehensive, we're strictly looking at the MAIL FROM / RCPT TO SMTP commands, as defined in Section 4.1.2. So let's start:...
https://www.netmeister.org/blog/email.html
#mail #email #validation
www.netmeister.org
Your E-Mail Validation Logic is Wrong
Nope,
you don't know how to validate an email address. Even
if you think you'd get the domain part right,
fuggeddabout the local part. Seriously.
you don't know how to validate an email address. Even
if you think you'd get the domain part right,
fuggeddabout the local part. Seriously.
Forwarded from OrangeDevOps
Недавно открыл для себя возможности BuildKit для сборки образов контейнеров.
Если не знакомы, то можно познакомится тут:
https://docs.docker.com/develop/develop-images/build_enhancements/
Субъективно скорость сборки образов увеличилась.
Есть еще пару интересных фич. BuildKit стоит за функцией мультиплатформенной сборки docker buildx и поддерживает возможность параллельного выполнения сборок несколькими рабочими процессами. BuildKit также поддерживает кеширование, различные внешние интерфейсы, более быстрые многоступенчатые сборки и т.п.
А надо то всего запустить:
DOCKER_BUILDKIT=1 docker build .
Или для docker-compose:
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
Захотелось понять как это работает. Наткнулся на статьи Адама Гордона Белла где он описывает прямую работу с Buildkit и сравнивает сборку докер образов с работой компилятора. Перевел их для вас. Если конечно хотите чуток углубится.
#docker #buildkit
https://habr.com/ru/post/550562/
Если не знакомы, то можно познакомится тут:
https://docs.docker.com/develop/develop-images/build_enhancements/
Субъективно скорость сборки образов увеличилась.
Есть еще пару интересных фич. BuildKit стоит за функцией мультиплатформенной сборки docker buildx и поддерживает возможность параллельного выполнения сборок несколькими рабочими процессами. BuildKit также поддерживает кеширование, различные внешние интерфейсы, более быстрые многоступенчатые сборки и т.п.
А надо то всего запустить:
DOCKER_BUILDKIT=1 docker build .
Или для docker-compose:
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
Захотелось понять как это работает. Наткнулся на статьи Адама Гордона Белла где он описывает прямую работу с Buildkit и сравнивает сборку докер образов с работой компилятора. Перевел их для вас. Если конечно хотите чуток углубится.
#docker #buildkit
https://habr.com/ru/post/550562/
Forwarded from ITTales :(){ :|:& };:
Тем временем вышла новая версия Booty - утилиты для создания загрузочных образов и накопителей.
Теперь booty сам собирает ядро с минимально необходимой конфигурации для его работы.
Все проблемы возникающие при использовании сторонних ядер решены.
Полученный initrd-образ полностью готов к загрузке, например, через PXE или через kexec.
Заявлена возможность работы с любыми дистрибутивами GNU/Linux.
https://github.com/sp00f1ng/booty
Теперь booty сам собирает ядро с минимально необходимой конфигурации для его работы.
Все проблемы возникающие при использовании сторонних ядер решены.
Полученный initrd-образ полностью готов к загрузке, например, через PXE или через kexec.
Заявлена возможность работы с любыми дистрибутивами GNU/Linux.
https://github.com/sp00f1ng/booty
Forwarded from Хитрый Питон
Статья о том, как запускать python-сервис с помощью systemd https://python.plainenglish.io/turning-your-python-script-into-a-real-program-cb702e16ed02
Medium
Turning your Python Script into a ‘Real’ Program
Level up your Python skills by making your programs system services — your future self will thank you.
Forwarded from k8s (in)security (D1g1)
Для тех, кто занимается обеспечением надежности (
-
-
-
-
Возвращаясь к тому, что
В контейнерных инфраструктурах (
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 не исключение) очень важно фиксировать инциденты ведь контейнеры/поды сущности эфемерные и часто завершаются, все унося с собой ...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