DevOps

📌Большая шпаргалка по System Design Здесь рассказывается о 99% самых используемых технологий в сфере System Design (а также о очень прикладных вещах), в том числе: ⏩как работает SSO ⏩как хранить пароли в БД ⏩как устроен HTTPS ⏩почему SSD быстрый ⏩про AWS Lambda ⏩откуда у Kafka такая скорость Много схем, графиков — всё как мы любим) 📎PDF @DevOPSitsec

🖥Управление GitHub-репозиториями: best practices Для DevOps-инженера управление GitHub-репозиториями имеет не меньшее значение, чем содержащийся в них код. В этом посте мы рассмотрим 3 совета по эффективному управлению репозиториями на GitHub, что-то из этого довольно очевидно, но уверен будет полезно. 〰️Четко придерживайтесь соглашения об именовании репозиториев ⏩Префикс для обозначения проекта или команды. Если в вашей организации есть несколько проектов или команд, названия репозиториев могут начинаться с префиксов, идентифицирующих проект или команду. Например, teamalpha_authentication_service или teambravo_data_pipeline. ⏩Описательные имена. Репозитории должны иметь описательные и конкретные названия, которые подскажут вам, что в них находится. Например, customer_support_ticketing_system или machine_learning_model_trainer. ⏩Указание на основной технологический стек. Это может быть особенно полезно для архитектур микросервисов. Например, image_processor_python или frontend_react_app. ⏩Версии или метки состояния. Если вы поддерживаете разные версии инструмента или библиотеки, или если в репозитории хранится что-то на определенной стадии разработки, укажите это в названии. Например, payment_gateway_v2 или inventory_management_deprecated. ⏩Избегайте специальных символов. Придерживайтесь букв и цифр с дефисами и символами подчеркивания, чтобы сохранить URL-совместимость и избежать путаницы. Например, invoice-generator или invoice_generator. ⏩Указание на юзкейс. Иногда полезно указать, является ли репозиторий библиотекой, сервисом, демо-версией или документацией. Например, authentication_lib, payment_api_service, demo_inventory_app, api_documentation. 〰️Классифицируйте репозитории по темам Добавлять темы в GitHub-репозитории полезно по нескольким причинам, в том числе: ⏩Видимость. Темы облегчают другим людям поиск вашего репозитория. Когда кто-то ищет определенную тему, в результаты поиска попадут репозитории, для которых указана эта тема. ⏩Организация. Темы помогают организовывать репозитории. Вы можете группировать репозитории по их назначению, технологическому стеку или любым другим критериям. ⏩Сообщество. Указание тем поможет вам познакомиться с людьми, которые интересуются теми же темами. Когда кто-то просматривает репозиторий с определенной темой, он может увидеть другие репозитории с той же темой. ⏩Ознакомление. Указанные темы предоставляют информацию о технологиях и инструментах, популярных в вашей организации. Вы можете использовать эту информацию для выявления тенденций и принятия обоснованных решений об используемых технологиях и инструментах. ⏩Стандартизация. Темы помогают стандартизировать категоризацию репозиториев. Вы можете использовать одни и те же темы во всех репозиториях, чтобы обеспечить согласованность. 〰️Используйте README.md для документирования репозитория Хорошо написанный файл README.md может вам помочь в следующих вещах: ⏩Привлечение контрибьюторов. Этот файл предоставляет потенциальным контрибьюторам информацию, необходимую для понимания проекта и начала работы с ним. ⏩Онбординг.README.md поможет новым членам команды освоиться в проекте. ⏩Документация. Файл README.md служит документацией для проекта. Он предоставляет пользователям информацию, необходимую для работы с проектом. ⏩Продвижение. Этот файл предоставляет потенциальным пользователям информацию, необходимую для понимания проекта и принятия решения о его использовании. ⏩Стандартизация.README.md помогает стандартизировать способ документирования проектов. Это обеспечивает последовательную структуру документирования проектов. 📎Ещё 7 полезных советов @DevOPSitsec

💻Kube No Trouble (kubent) — инструмент для проверки использования устаревших API в кластере Kubernetes Особенно это актуально сейчас, на фоне распространения Kubernetes 1.16, многие API становятся устаревшими. kubent без проблем работает: — с YAML или JSON — с kubectl, используется аннотация kubectl.kubernetes.io/last-applied-configuration — с Helm v3 ⏩Установка kubent: sh -c "$(curl -sSL https://git.io/install-kubent)" ну или brew install kubent ⏩Функционал легко посмотреть через -h, как обычно: ./kubent -h Usage of ./kubent: -A, --additional-annotation strings additional annotations that should be checked to determine the last applied config -a, --additional-kind strings additional kinds of resources to report in Kind.version.group.com format -c, --cluster enable Cluster collector (default true) -x, --context string kubeconfig context -e, --exit-error exit with non-zero code when issues are found -f, --filename strings manifests to check, use - for stdin --helm3 enable Helm v3 collector (default true) -k, --kubeconfig string path to the kubeconfig file -l, --log-level string set log level (trace, debug, info, warn, error, fatal, panic, disabled) (default "info") -o, --output string output format - [text|json|csv] (default "text") -O, --output-file string output file, use - for stdout (default "-") -t, --target-version string target K8s version in SemVer format (autodetected by default) -v, --version prints the version of kubent and exits 🖥GitHub 2.6K ⭐️ @DevOPSitsec

💻Девопс-2024: чего ожидать и что изменится Девопс сейчас развивается очень быстро, и этому есть множество причин. Девопс-подход к разработке ПО обеспечивает быстрый выпуск кода и его тестирование, что сильно экономит время. В этом посте посмотрим, какие тенденции будут определять отрасль и каким будет их влияние в 2024 году ⏩Автоматизация с помощью нейросетей и моделей машинного обучения Поскольку главная задача девопса — автоматизировать как можно больше процессов, чтобы ускорить разработку, нейросети и модели машинного обучения будут всё больше интегрированы в эту работу. Такие инструменты могут упростить анализ кода, тестирование, развёртывание, мониторинг и обратную связь. Уже появилось понятие AIOps, которое состоит в том, чтобы применять нейросети и модели машинного обучения для автоматизации множества процессов, которые раньше выполнялись вручную. С помощью нейросетей и моделей машинного обучения можно выявлять и решать проблемы, прогнозировать и предотвращать сбои, а также повышать безопасность систем. Это обеспечит большую эффективность разработки, улучшит профилактику потенциальных проблем и снизит затраты. ⏩Интеграция безопасности на всех этапах Интеграцию безопасности в девопс называют DevSecOps. При этом подходе вопросы безопасности учитываются на протяжении всего цикла разработки, в результате чего готовые приложения получаются более безопасными. Для DevSecOps также можно использовать механизмы автоматизации. Обеспечить безопасность на всех этапах девопса — от планирования до производства — можно будет и с помощью микросервисной архитектуры и бессерверных вычислений. ⏩Рост микросервисной архитектуры Для традиционной монолитной архитектуры характерны большие тесно связанные приложения, но по мере их увеличения появляются сложности. Монолиты трудно разрабатывать и развёртывать независимо и быстро вносить в них изменения. Масштабировать такие приложения дорого и долго, а сбой в одном компоненте может вывести из строя всю систему. При проектировании микросервисной архитектуры приложение состоит из сервисов, которые слабо связаны друг с другом. За счёт этого взаимодействие между компонентами постоянное, сбои изолированы, а развёртывание быстрое и не влечёт рисков. Это упрощает код, его масштабируемость и разработку в целом. Интеграция девопса в создание микросервисов обеспечивает плавное взаимодействие между командами разработки и эксплуатации, а развёртывание одного компонента не будет затрагивать другие. ⏩Упрощение и рост доступности Kubernetes Kubernetes — это система управления приложениями, которые работают друг с другом и решают задачи в одном контейнере, который работает как виртуальная машина. Но для многих сложность управления Kubernetes остаётся препятствием для её использования. Поэтому ожидается, что платформа будет меняться в сторону упрощения, чтобы разработчики могли использовать возможности Kubernetes, не будучи экспертами в тонкостях её работы.Kubernetes: что нужно знать, чтобы получать 350 000 в месяц Более простые интерфейсы и более автоматизированные процессы Kubernetes сделают её технологии доступнее для разработчиков. Благодаря этому контейнеризацию станут чаще применять в отраслях, где она не была популярной, например в финансах, производстве и розничной торговле. ⏩Развитие low-code и зеро-кода Платформы low-code и зеро-код — это инструменты, которые позволяют пользователям создавать приложения с минимальным использованием кода или без его написания. Благодаря low-code и зеро-коду нетехнические специалисты смогут участвовать в девопс-процессах, таких как создание прототипов, тестирование, развёртывание и обновление приложений. Это упростит и сократит циклы разработки и позволит устранить дефицит навыков. Вот мы и обсудили, в каком направлении движется DevOps А что вы думаете по этому поводу? @DevOPSitsec

🌟Вышел OpenSSH 9.7 Вышел проект OpenSSH 9.7. В новой версии открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP началось внесение изменений, предшествующих будущему прекращению поддержки ключей на базе алгоритма DSA. ⏩В OpenSSH 9.7 предоставлена опция для отключения DSA на стадии компиляции, но сборка по умолчанию с поддержкой DSA пока сохранена. В следующем выпуске режим сборки будет изменён на отключение DSA по умолчанию, а в начале 2025 года реализация DSA будет удалена из кодовой базы проекта. ⏩В новом выпуске OpenSSH предложен новый тип таймаутов в ssh и sshd, включаемый через указания значения global в директиве ChannelTimeout. В этом режиме OpenSSH отслеживает все открытые каналы и закрывает их разом, если во всех из них за указанный промежуток времени отсутствовал трафик. Например, когда к хосту одновременно открыты каналы для SSH-сеанса и перенаправления x11, новый режим позволяет закрыть сразу оба канала, если они неактивны, вместо раздельного отслеживания таймаутов для каждого канала. ⏩Также из изменений в OpenSSH 9.7 отмечается значительное улучшение тестирования совместимости с проектом PuTTY. @DevOPSitsec

🖥Подборка команд Docker Ловите — самые востребованные команды Docker Освежите эту важную информацию, чтобы она переместилась в долговременную память) 📎Полезный сайт с подборкой команд и примерами @DevOPSitsec

🔄Как упростить работу с YAML-файлами YAML — популярный язык для конфигурационных файлов, широко используемый DevOps в подходе «Инфраструктура как Код» (IaC). Давайте рассмотрим несколько советов, которые помогут упростить работу с yml-файлами. Используйте специализированные редакторы и плагины Очевидный совет, но мало ли; работа с YAML в правильной среде даёт: 🔘подсветку синтаксиса 🔘автодополнение кода 🔘проверку отступов 🔘сниппеты (шаблоны кода) Популярные плагины: YAML Support для VS Code, yaml-mode для Emacs, drawspaces для Gedit. Генерируйте YAML из кода Ручное написание сложных конфигураций на YAML не так приятно. Проще сначала определить нужную структуру данных в виде словарей и массивов в том же Python, а затем сгенерировать из нее YAML. Есть такая структура: data = { "server": { "port": 8000, "enabled": true }, "clients": [ {"name": "Client1", "address": "192.168.1.100"}, {"name": "Client2", "address": "192.168.1.101"} ] } С помощью PyYAML легко конвертируем в YAML-файл: import yaml with open('config.yaml','w') as f: f.write(yaml.dump(data)) Получаем: server: port: 8000 enabled: true clients: - address: 192.168.1.100 name: Client1 - address: 192.168.1.101 name: Client2 Создавайте шаблоны Намного проще взять существующую заготовку, подставить в нее данные приложения и получить готовый YAML-файл. Например, при развертывании микросервисов в Kubernetes удобно иметь шаблон манифеста deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: <service_name> labels: app: <service_name> spec: replicas: 3 template: metadata: labels: app: <service_name> spec: containers: - name: <service_name> image: <image>:<tag> ports: - containerPort: <port> --- apiVersion: v1 kind: Service ▶️Ещё несколько полезных советов по YAML @DevOPSitsec

📌Всё про сортировку веток Git Запустив git branch в репозитории, вы обычно получаете список веток в алфавитном порядке. Это может раздражать, когда у вас много веток (если только у вас нет очень жесткой системы именования по номеру тикета или чего-то подобного). ⏩Не проблема, это можно изменить. Выполните в вашем репозитории следующую команду: git branch --sort=-committerdate Это отсортирует все ваши ветки по дате их последнего коммита Для сортировки доступны такие опции: - authordate - committerdate - creatordate - objectsize - taggerdate ⏩Кроме того, если хотите всегда сортировать по одному из этих параметров, можно установить это в настройках: git config --global branch.sort -committerdate ⏩Также можно задать псевдоним: git config --global alias.brcd "branch --sort=-committerdate". Подробнее о работе с ветками можно почитать тут, ловите ссылки: 📎Ветвление Git с примерами из реальной жизни 📎Как удалить ветку в Git 📎Как переименовать локальную ветку в Git @DevOPSitsec

🔺Дизайн систем — основные понятия и принципы ⏩CAP – Согласованность/целостность, доступность и устойчивость к разделению. Это означает, что версии одной и той же информации, хранящиеся на разных серверах, не противоречат друг другу и любой запрос к распределённой системе завершается корректным откликом. Такие системы возможны при поддержке ACID-требований к транзакциям ⏩BASE — "в основном доступный, мягкое состояние, постепенно согласованный". Подход BASE ставит упор на доступность данных и их масштабируемость, позволяя достигнуть этих целей за счет компромисса в отношении согласованности данных. ⏩SOLID — принцип единственной ответственности, принцип открытости/закрытости, принцип подстановки Барбары Лисков, принцип разделения интерфейса, принцип инверсии зависимостей ⏩KISS — принцип, запрещающий использование более сложных средств, чем необходимо И ещё некоторые важные требования к техническим системам в плане отказоустойчивости и т.д. на другом изображении @DevOPSitsec

💻Atlas Kubernetes Operator — — это контроллер Kubernetes, который использует Atlas для управления схемой вашей базы данных. Он осуществляет всю логику взаимодействия и работает non-stop. Atlas Kubernetes Operator позволяет вам определить желаемую схему и применить ее к вашей базе данных с помощью Kubernetes API Пользователи могут использовать Atlas DDL (язык определения данных) или обычный SQL для описания нужной схемы базы данных и использовать инструмент командной строки для планирования и применения миграций в своих системах. Фичи: 🔘Поддержка декларативных миграций для схем, определенных в Plain SQL или Atlas HCL. 🔘Обнаружение рискованных изменений, таких как случайное удаление столбцов или таблиц, и определение политики для их обработки. 🔘Поддержка версионных миграций. 🔘Поддерживаемые БД: MySQL, MariaDB, PostgresSQL, SQLite, TiDB, CockroachDB. 🔘Декларативные миграции схем 🖥Проект на GitHub @DevOPSitsec

⚡️ Шпаргалка для алгособеса 2 — графовые и строковые алгоритмы 📌Читать дальше 📌Часть 1: алгоритмическая сложность, структуры данных, методы сортировки и Дейкстра @DevOPSitsec

➡️Нереальный открытый учебник по Computer Science и алгоритмам 🔗eecs376.github.io/notes/algorithms.html Прокачивайся — и тогда ИИ тебя не заменит) @DevOPSitsec