REST Servers in Go
- Part 1 - standard library (this post)
- Part 2 - using a router package
- Part 3 - using a web framework
- Part 4 - using OpenAPI and Swagger
- Part 5 - middleware
#go #golang #REST

https://link.medium.com/iJWlWdK3Zeb
#socat #socket #cat

https://themes.vscode.one/
#vscode #vs #theme

https://www.docker.com/blog/compiling-containers-dockerfiles-llvm-and-buildkit/
#container #buildkit #docker

https://open.spotify.com/album/5QXiTNcdXFrlJ507thp7Wn?si=uvFluhZyRW6gSoJUf4YTRw&utm_source=copy-link
#music #spotify #solarfields

https://betterprogramming.pub/my-ultimate-makefile-for-golang-projects-fcc8ca20c9bb
#go #golang #make

https://medium.com/tanker-blog/automating-version-number-updates-what-could-go-wrong-75edd190ee47
#semver #bump

https://github.com/dmerejkowsky/tbump
#github #bump #tbump

https://blog.sigstore.dev/ssh-is-the-new-gpg-74b3c6cc51c0
#ssh #sshkeygen #sign #PKI

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

Недавно открыл для себя возможности 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://baykara.medium.com/docker-resource-management-via-cgroups-and-systemd-633b093a835c
#docker #limit #cgroups #systemd

https://habr.com/ru/post/550634/
#docker #dockercompose

https://github.com/il-da-r/dockerufw
#docker #ufw #iptables #github

Тем временем вышла новая версия Booty - утилиты для создания загрузочных образов и накопителей.

Теперь booty сам собирает ядро с минимально необходимой конфигурации для его работы.
Все проблемы возникающие при использовании сторонних ядер решены.

Полученный initrd-образ полностью готов к загрузке, например, через PXE или через kexec.

Заявлена возможность работы с любыми дистрибутивами GNU/Linux.

https://github.com/sp00f1ng/booty

Статья о том, как запускать python-сервис с помощью systemd https://python.plainenglish.io/turning-your-python-script-into-a-real-program-cb702e16ed02

Для тех, кто занимается обеспечением надежности (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 не исключение) очень важно фиксировать инциденты ведь контейнеры/поды сущности эфемерные и часто завершаются, все унося с собой ...