DevOps

📌20 полезных, но малоиспользуемых команд Git

Держите, это кликабельный список:
⏩ Git Web — открыть встроенный графический интерфейс
⏩ Git Notes — прикрепить дополнительную информацию к коммитам
⏩ Git Bisect — дебажить как про
⏩ Git Grep — найти что угодно
⏩ Git Archive — сжать проект для шеринга
⏩ Git Submodules — импортировать другие репозитории в ваш
⏩ Git Bugreport — скомпилировать баг-репорт с информацией о системе
⏩ Git Fsck — проверить и восстановить недоступные объекты
⏩ Git Stripspace — удалить пробелы в конце текста
⏩ Git Diff — сравнить изменения между двумя файлами
⏩ Git Hooks — выполнить скрипт при запуске команды git
⏩ Git Blame — показать, кто написал данную строку
⏩ Git Large File Storage — сохранить большие файлы в git
⏩ Git Garbage Collection — оптимизировать git-репо
⏩ Git Show — легко просмотреть любой объект git
⏩ Git Describe — дать читаемое имя на основе последнего тега
⏩ Git Tag — создать метки версий в определенных точках
⏩ Git Reflog — список всех действий, выполненных над репозиторием
⏩ Git Log — просмотреть журнал коммитов и диаграммы ветвей
⏩ Git Cherry Pick — вытащить фичу в вашу ветку
⏩ Git Switch — быстро переключиться между ветками

Пользуйтесь)

@DevOPSitsec

🌟 Вышел WingetUI (UnigetUI) 3.0

⏩13 марта 2024 года состоялся релиз WingetUI (UnigetUI) 3.0. Это графический инструментарий с открытым исходным кодом, который позволяет устанавливать, удалять и обновлять приложения на устройствах Windows с помощью наиболее распространённых консольных менеджеров (CLI) для Windows 10 и Windows 11, включая Windows Package Manager (winget), Scoop и Chocolatey, а также Pip, Npm, .NET Tool и PowerShell Gallery.

⏩Фактически WingetUI превратился в поддержку различных менеджеров пакетов, а не только Winget, что привело к тому, что имя WingetUI сбивает с толку новых пользователей и не отражает основную суть этого приложения. В настоящее время в WingetUI доступно более 14 тыс. пакетов (Winget, Scoop и Chocolatey).
Автор проекта Марти Климент пояснил, что он с каждым днём наблюдает, как пользователи всё чаще путают WingetUI и winget, что вполне ожидаемо, учитывая небольшую разницу между этими двумя названиями. Поэтому WingetUI скоро будет переименован в UnigetUI.

@DevOPSitsec

📌Большая шпаргалка по 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