💪🤓 Поднимаем домашний сервер со своим доменом

Тема не претендует на звание открытие месяца, но автор очень доступным языком все толкует, что начинающим будет весьма полезно узнать про DNS, OpenVPN, сети, маршрутизацию, Linux и прочие околотематические штуки. Приятного просмотра 😉

Смотреть видео

#гайд

👀 6 способов привлечь внимание работодателя

Как рассказать, что вы умеете программировать и хотите получать за это деньги, не говоря об этом напрямую:

1️⃣ Оформить профиль на Линкедин, Гитхаб и Стековерфлоу
2️⃣ Участвовать в хакатонах
3️⃣ Начать вести свой блог об IT
4️⃣ Стать участником конференций от IT-гигантов
5️⃣ Создать канал на YouTube и рассказывайте об IT
6️⃣ Написать в личку

👉 Подробнее о каждом пункте читайте в статье

💪🔥 От AI к устойчивому развитию: почему новейшие центры обработки данных используют сеть 400G

400G — относительно новая технология, и она не получила такого широкого распространения в отрасли, как 100G, хотя ситуация начинает меняться. В этой статье обсуждается, почему решено начать использование 400G, требования к дизайну и архитектурные детали ЦОД 400G, а также затронутся некоторые проблемы, с которыми столкнулись первые пользователи, и извлеченных уроков. В заключение автор расскажет о планах на будущее по продолжению разработки с использованием новой технологии.

Читать статью

#почитать

🤔 Очередной #дайджест статей и инструментов по DevOps

✔️ Контейнеры: Rootful, Rootless, Privileged and Super Privileged — различные типы, как они создают свою изоляцию, возможностях ядра, оверлейных файловых системах, seccomp и SELinux

✔️ System Design 101 — рассматриваются протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование и прочее

✔️ Затраты на микросервисы — как правильно начать создавать микросервис, что учесть и как действовать

✔️ Prometheus и централизованное хранилище — когда вам это нужно, как это работает и что такое Mimir

✔️ Руководство по тестированию в Terraform — поддержание порядка в тестах, валидациях, проверках и политиках

🤔✏️ Как надо (и как не надо) разрабатывать REST API

➖ Используйте существительные во множественном числе для обозначения коллекций
➖ Не добавляйте ненужные сегменты пути
➖ Не добавляйте .json или другие расширения к URL-адресу
➖ Не возвращайте массивы в качестве ответов верхнего уровня
➖ Не возвращайте map-структуры
➖ Используйте строки для всех идентификаторов
➖ Применяйте префикс в своих идентификаторах
➖ Не используйте 404 для обозначения «не найдено»
➖ Будьте последовательными
➖ Используйте структурированный формат ошибок

Подробное объяснение с примерами кода тут

#туториал

iptables-tracer

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

$ iptables-tracer -f "-s 192.0.2.1 -p tcp --dport 443" -t 30s
14:42:00.284882 raw    PREROUTING   0x00000000 IP 192.0.2.1.36028 > 203.0.113.41.443: Flags [S], seq 3964691400, win 29200, length 0  [In:eth0 Out:]
14:42:00.287255 mangle PREROUTING   0x00008000 IP 192.0.2.1.36028 > 203.0.113.41.443: Flags [S], seq 3964691400, win 29200, length 0  [In:eth0 Out:]
14:42:00.288966 nat    PREROUTING   0x00008000 IP 192.0.2.1.36028 > 203.0.113.41.443: Flags [S], seq 3964691400, win 29200, length 0  [In:eth0 Out:]
14:42:00.290545 mangle FORWARD      0x00008000 IP 192.0.2.1.36028 > 198.51.100.8.443: Flags [S], seq 3964691400, win 29200, length 0  [In:eth0 Out:eth1]
14:42:00.292123 filter FORWARD      0x00008002 IP 192.0.2.1.36028 > 198.51.100.8.443: Flags [S], seq 3964691400, win 29200, length 0  [In:eth0 Out:eth1]
14:42:00.293164 mangle POSTROUTING  0x00008002 IP 192.0.2.1.36028 > 198.51.100.8.443: Flags [S], seq 3964691400, win 29200, length 0  [In: Out:eth1]
14:42:00.293780 nat    POSTROUTING  0x00008002 IP 192.0.2.1.36028 > 198.51.100.8.443: Flags [S], seq 3964691400, win 29200, length 0  [In: Out:eth1]

Что означает 2>&1?

Это про стандартные потоки вывода. Они имеют файловые дескрипторы:

stdout — 1 (общий поток вывода)
stderr — 2 (поток с ошибками)

Получается (2>&1) = stderr > stdout — направляем поток с ошибками, в стандартный поток вывода. Ошибки будут выводиться на экран в терминале.

Логичным было бы сделать конструкцию: 2>1. Но увы, эта схема отработает другую логическую операцию. Поток с ошибками stderr будет писать все данные в файл, у которого название будет 1.

Для этого и требуется указать символ & (амперсанд) перед stdout. Это будет интерпретировано как файловый дескриптор, а не обычный файл.

А почему тогда не &2>&1 ?
Символ & интерпретируется как файловый дескриптор только в контексте перенаправления.

Операция command &2>&1 анализируется так: command & 2>&1 — команда command будет выполнятся в фоновом режиме. А затем начнет выполнятся команда 2 с перенаправлением на стандартный вывод stdout.

Есть альтернатива с оператором |&.

|& это сокращенный вариант от 2>&1 |

Пример:

script.sh |& tee -a /var/log/script.log

Все что script.sh выведет в потоки stdout и stderr, будет перенаправлено в файл script.log.

В официальной документации можно подробнее изучить эту штуку.

#memes

Я на собеседовании