RTzRa's hive - devops

Cross-shell prompt

anonymous@undisclosed.example.com (Anonymous) — Fri, 07 Jan 2022 15:24:31 +0000

Cross-shell prompt

Минималистичная, быстрая и бесконечно настраиваемая командная строка для любой оболочки: Linux (bash/zsh/fish/etc), Windows, MacOS.

https://starship.rs/

cross, shell, prompt, linux, windows, macos

DevOps: Database Cheat Sheet

anonymous@undisclosed.example.com (Anonymous) — Sat, 16 Sep 2023 10:07:47 +0000

DevOps: Database Cheat Sheet

Взял здесь: https://blog.bytebytego.com/p/ep73-cheat-sheet-of-different-databases

database, cheat, sheet, базы данных

DevOps: 12-ти факторное приложение

anonymous@undisclosed.example.com (Anonymous) — Mon, 18 Oct 2021 00:50:57 +0000

DevOps: 12-ти факторное приложение

Каждый фактор полностью расписан тут: https://12factor.net/ru/

Кодовая база. Одна кодовая база, отслеживаемая в системе контроля версий, – множество развёртываний
Зависимости. Явно объявляйте и изолируйте зависимости
Конфигурация. Сохраняйте конфигурацию в среде выполнения
Сторонние службы (Backing Services). Считайте сторонние службы (backing services) подключаемыми ресурсами
Сборка, релиз, выполнение. Строго разделяйте стадии сборки и выполнения
Процессы. Запускайте приложение как один или несколько процессов не сохраняющих внутреннее состояние (stateless)
Привязка портов (Port binding). Экспортируйте сервисы через привязку портов
Параллелизм. Масштабируйте приложение с помощью процессов
Утилизируемость (Disposability). Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы
Паритет разработки/работы приложения. Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими
Журналирование (Logs). Рассматривайте журнал как поток событий
Задачи администрирования. Выполняйте задачи администрирования/управления с помощью разовых процессов

12factor, twelve-factor app, 12 факторное приложение

DevOps: Шпаргалки

anonymous@undisclosed.example.com (Anonymous) — Thu, 26 Aug 2021 20:11:20 +0000

DevOps: Шпаргалки

https://devhints.io/?q=devops

devops, cheatsheets

DevOps: Проекты Cloud Native Computing Foundation (CNCF)

anonymous@undisclosed.example.com (Anonymous) — Fri, 25 Mar 2022 18:54:14 +0000

DevOps: Проекты Cloud Native Computing Foundation (CNCF)

Информация о всех проектах Cloud Native Computing Foundation (CNCF) на одной страничке: https://github.com/cncf/toc/blob/main/docs/projects.md

На страничке есть масса информации, гораздо удобнее https://cncf.io/ и https://landscape.cncf.io/

cncf, projects, devops

DevOps: Курсы и обучалки

anonymous@undisclosed.example.com (Anonymous) — Sat, 16 Sep 2023 11:38:36 +0000

DevOps: Курсы и обучалки

Зарубежные:

Российские:

courses, курсы, обучение

DevOps: Диаграммы

anonymous@undisclosed.example.com (Anonymous) — Sun, 09 Jan 2022 13:54:09 +0000

DevOps: Диаграммы

Для рисования DevOps и прочих диаграмм хорошо подходит https://www.draw.io/

Пример нарисованного: https://www.reddit.com/r/homelab/comments/ket7fx/ive_super_upgraded_my_nas_and_a_few_other_things/

Советы по оформлению сетевых диаграмм: http://networkdiagram101.com

devops, диаграмма

DevOps: EOL (End OF Life)

anonymous@undisclosed.example.com (Anonymous) — Tue, 10 Jan 2023 09:57:23 +0000

DevOps: EOL (End OF Life)

Очень часто бывает нужно быстро посмотреть когда наступает (скорее, уже наступил, хе-хе) срок поддержки какого-то часто используемого программного обеспечения, дистрибутива и т.д. Лазить по официальным сайтам, гитхабам и прочему не всегда удобно, да еще и искать нужно. Случайно наткнулся на https://endoflife.date/ - там централизованно собрана информация. Они же на гитхабе: https://github.com/endoflife-date/endoflife.date

eol, end of life

DevOps: DevOps Questions & Exercises

anonymous@undisclosed.example.com (Anonymous) — Thu, 26 Aug 2021 20:12:38 +0000

DevOps: DevOps Questions & Exercises

https://github.com/bregman-arie/devops-exercises

devops, questions, exercises

DevOps: Кровавые капельки опыта

anonymous@undisclosed.example.com (Anonymous) — Wed, 09 Aug 2023 09:49:48 +0000

DevOps: Кровавые капельки опыта

Деплой в пятницу, да еще и вечером - плохая затея. Очень плохая. Сам не делай и коллегам не давай.
Поднял любой сервис - настрой лимиты, будь мужиком. Лимиты на CPU/Memory, на кол-во соединений, на все, что в теории может завалить твой сервис. Поверь, коллеги куда как опаснее врагов. Обязательно поломают если давать такую возможность.
Написал скрипт - проверь его, подробнее тут: DevOps: Проверяй работу скриптов. Проверил? Прогони в тестовой песочнице и на тестовых данных.
Храни скрипты и все нужное и полезное в Git - всегда будешь знать кто и когда вносил изменения, искать крайнего становится неизмеримо легче.
Бэкапы уже делаешь? 3-2-1? 3-2-1-1-0? https://community.veeam.com/blogs-and-podcasts-57/3-2-1-1-0-golden-backup-rule-569 А теперь вопрос: бэкапы тестируешь? Нет? Тогда это не бэкапы.
Каков RTO (Recovery Time Objective) для восстановления из бэкапа, влазим в SLA для сервисов?
Храни чувствительные данные в предназначенных для этого местах: Vault, Vautlwarden, KeePass и т.д. Эксельки, текстовые файлики, листики и прочие места где все лежит в открытом виде - это 100% утечка. Разумеется, обновление и патчинг данных сервисов должен быть с повышенным приоритетом. Плюсы - это надежно, проще раздавать и отнимать права, проще отслеживать изменения (и их авторов), проще защищать, не нужно править скрипты.
Пишите видео сеансов пользователей? Доступ должен быть максимально закрыт. Лично знаю историю как пентестеры получили доступ к видеозаписи сеанса, посмотрели как один из админов копипастит пароли из текстового файлика (а потому что буфер обмена был запрещен «для безопасности») и поимели всю инфраструктуру.
Не делай большие и жирные сервисы - чем больше объем, тем дольше восстановление. Особенно касается файловых серверов. Вытаскивать из бэкапа 20 Тб - это к долгому ожиданию.
Есть сервера-снежинки? 100% гарантия геморроя в будущем. Меры митигации: etckeeper, бэкапы всего сервера целиком и хотя бы /etc. В идеале - отдельный ансибловый плейбук (роль) для раскатки.
Случился факап - сообщи коллегам, поставь всех заинтересованных в известность, прикинь примерные сроки. Если со сроками непонятно (а в 95% случаев это именно так) - сообщи контрольный срок когда у тебя появятся новые данные: «Коллеги, упал сервис, ведем восстановление. Примерные сроки неизвестны, более точно сможем сказать через пару часов».
Важный прод? Дублируй каналы, датацентры, сервисы. Предварительно стоит посчитать что дешевле: потери из-за простоя и потери или затраты на отказоустойчивость.

devops, experience, опыт, кровавый энтерпрайс

DevOps: Как разгребать проблемы

anonymous@undisclosed.example.com (Anonymous) — Fri, 06 Oct 2023 14:36:58 +0000

DevOps: Как разгребать проблемы

Вводная: Что-то пошло ну очень не так и ситуацию можно описать как «шеф, все пропало» или «мы в крутом пике». Т.е. это не рядовой факап, а прямо катастрофа высокого уровня.

Задача: Вылезти максимально быстро и желательно с минимальными потерями из данной ситуации

Пути выхода из ситуации и решение проблемы

1. Первое что нужно сделать - остановиться и понять в какой ситуации мы оказались. Казалось бы - горит и даже сильно уже припекает, надо руки в ноги и тушить. Увы, скоропалительными действиями можно нанести еще больший вред. Поэтому останавливаемся, убираем руки от клавиатуры и оцениваем ситуацию. Здесь главное ответить на вопрос о масштабе события: насколько оно глобальное, имеет ли тенденцию к ухудшению, насколько быстро все доломается окончательно и т.д. Самое сложное - понять насколько тяжела ситуация, т.к. лавина начинается из-за небольшого камешка, а уже через несколько минут ее невозможно остановить. Так же важно зафиксировать все начальные условия: что и когда приключилось, начать вести хронологию событий. Если ваша команда практикует написание Post Mortem'ов - самое время создавать новый.

2. Подключение ресурсов (если они у нас есть). Как правило, тяжелая ситуация подразумевает невозможность сделать все целиком самому: отсутствие компетенций во всем подсистемам, недостаток времени и сил, возможно требуются дополнительные ресурсы (люди, железо и прочее). На этом этапе необходимо подключать руководство, коллег, дополнительные мощности. Задача в распараллеливании задач и подготовке к дальнейшим действиям. Если вам прямо сейчас не нужна помощь - это хорошо, но чтобы эта самая помощь была в ближайшем будущем надо ей озаботиться уже сейчас (например, иногда сложно разбудить человека или он недоступен в текущий момент или просто далеко от компьютера). Так же на данном этапе необходимо провести назначение единого ответственного, к которому стекается вся информация и решения. Как правило на этом этапе уже возникает некоторое понимание масштабов и можно провести первичную оценку времени по восстановлению работы, как минимум фраза «потребуется примерно 2 часа на устранение» звучит намного понятнее чем «да хрен его знает».

3. Разгребание проблемы. Выполняем пошагово, синхронизируя свои действия с командой и коллегами. Конкретную работу должен делать кто-то один, не должно быть картины «мы вдвоем подключились к серверу и параллельно пытались починить» - как правильно это приводит к проблемам, т.к. каждый из участников получает искаженную картину. Если на данном этапе открываются новые обстоятельства (а в 95% это так и случается) - производим переоценку ситуации, и, соответственно, время на ее устранение. Если стало понятно что требуются дополнительные затраты (времени, людей, ресурсов) - возвращаемся к пункту 2. Очень важно понимать что гораздо лучше честно сказать «ситуация изменилась, произошло то-то и то-то, время на восстановление увеличивается по нашей оценке до ХХ часов» чем пытаться впопыхах уложиться в первично обозначенное время, мол «пацан сказал - пацан сделал». На этом этапе главное не накосячить еще больше из-за спешки и не привести ситуацию к варианту «сами угробили все до чего дотянулись руки».

4. Стабилизация обстановки. Вроде все понятно по текущей ситуации, нужные люди устраняют проблемы. Освободившиеся ресурсы можно переключить на вторичные задачи: помощи наиболее загруженным специалистам, исключения повторения инцидента, общение с руководством/клиентами, ведение Post Mortem'а, или вообще отправить отдыхать если они больше не нужны.

5. Проведение анализа событий. Здесь основная задача - оценить что нужно сделать для исключения повторения инцидента, запланировать и провести работы. Разумеется, все это должно быть отражено в базе знаний и т.д.

решение инцидентов, все в огне, горим, паника

DevOps: Иконки, картинки, бейджики

anonymous@undisclosed.example.com (Anonymous) — Sat, 08 Jan 2022 11:19:31 +0000

DevOps: Иконки, картинки, бейджики

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

VectorLogoZone - более 3.000 лого! https://www.vectorlogo.zone/ и https://github.com/VectorLogoZone/vectorlogozone
Огромное количество SVG-иконок на любой вкус: https://simpleicons.org
Красивые бейджики: https://shields.io и еще тут: https://github.com/Naereen/badges
Пиктограммы - http://sergeychikin.ru/365/
Emoji - всякие и разные:

DevOps: Что же это такое

anonymous@undisclosed.example.com (Anonymous) — Wed, 18 Jan 2023 15:24:14 +0000

DevOps: Что же это такое

DevOps, согласно https://ru.wikipedia.org/wiki/DevOps - это набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и услуги.

По факту DevOps - это расширенный набор целей и задач, за которые ранее отвечали системные администраторы, а до них это делали инженеры. Мир меняется, меняются цели и задачи. Точнее сказать - изменяется объем и направление этих задач. А в остальном все остается как прежде: нужно чтобы все работало.

CNCF Cloud Native Interactive Landscape - https://landscape.cncf.io/

devops, девопс, что это такое

DevOps: Карта знаний и умений

anonymous@undisclosed.example.com (Anonymous) — Tue, 21 Dec 2021 07:13:24 +0000

DevOps: Карта знаний и умений

Взято тут: https://roadmap.sh/devops, оригинал тут: https://github.com/kamranahmedse/developer-roadmap

devops, roadmap, девопс, карта, знания, умения

DevOps: Утилиты и сервисы для работы с IP

anonymous@undisclosed.example.com (Anonymous) — Tue, 06 Sep 2022 08:18:02 +0000

DevOps: Утилиты и сервисы для работы с IP

Сервисы для получения информации об IP-адресах:

https://2ip.ru/ - один из самых шикарных сервисов, позволяет… Да сложно сказать что он НЕ умеет, огромная подборка сервисов для получения разносторонней информации
http://ifconfig.co/ - позволяет получать подробную информацию о вашем текущем IP, например:
```
curl ifconfig.co/json | jq
```
Так же можно развернуть данный сервис у себя: https://github.com/mpolden/echoip
https://mylocation.org/ - Показывает расположение выходной точки по IP-адресу
http://ip-api.com/ - позволяет запрашивать информацию о произвольном адресе, например:
```
curl http://ip-api.com/json/1.1.1.1 | jq
```

internet, ip, network

DevOps: Periodic Table of DevOps Tools

anonymous@undisclosed.example.com (Anonymous) — Fri, 01 Oct 2021 02:32:59 +0000

DevOps: Periodic Table of DevOps Tools

https://digital.ai/periodic-table-of-devops-tools

Periodic, Table, of, DevOps, Tools

DevOps: Проверяй работу скриптов

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Nov 2022 09:31:28 +0000

DevOps: Проверяй работу скриптов

Если часто приходится писать скрипты то хорошо бы иметь возможность проверить его на ошибки до момента запуска.

«Да ладно, скрипт простенький, где там ошибаться-то. И вообще столько лет пишу, мне и так хорошо» - так думают многие (и я до сегодняшнего дня). Хренушки, однажды настанет придет симпатичный белый писец и будет поздно. Бэкапы это здорово, но зачем делать лишнюю работу и дергаться из-за RTO?

В общем рекомендую использовать https://www.shellcheck.net/

ShellCheck - это инструмент, который позволяет улучшать и исправлять скрипты командной строки Linux. Он способен обнаруживать множество распространённых недоработок и ошибок в их коде.

Репозиторий на GitHub: https://github.com/koalaman/shellcheck

Проверка онлайн (https://www.shellcheck.net/) или установка локально.

Debian:

sudo apt install shellcheck

EPEL:

yum -y install epel-release
sudo yum install ShellCheck

Проверка локально в терминале:

shellcheck yourscript

А здесь можно найти неплохую шпаргалку по bash: https://goalkicker.com/BashBook/

Для проверки скриптов на PowerShell можно использовать PSScriptAnalyzer - https://github.com/PowerShell/PSScriptAnalyzer/

DevOps: Шоткаты командной строки

anonymous@undisclosed.example.com (Anonymous) — Sat, 29 Jan 2022 11:31:29 +0000

DevOps: Шоткаты командной строки

linux, cli, bash, zsh, shell, shortcut, сокращение, шоткат

Уровни SLI/SLA/SLO

anonymous@undisclosed.example.com (Anonymous) — Tue, 07 Dec 2021 14:28:53 +0000

Уровни SLI/SLA/SLO

Описание что такое SLI/SLA/SLO: https://cloud.google.com/blog/products/gcp/sre-fundamentals-slis-slas-and-slos

Полезные ресурсы для расчета показателей:

Копипаста взята отсюда: https://habr.com/ru/company/proto/blog/538966/

Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

Если компания предоставляет SLA клиентам, обычно при прописывании SLO берутся в расчет установленные показатели SLA. Так как в случае не достижения SLO это напрямую отразиться на SLA, что приведет к определенным последствиям для бизнеса в лице нарушения договорных обязательств перед клиентами или даже штрафам.

В концепции SLI и SLO присутствует индикатор Error Budget или, как его иногда называют, «право на ошибку». Error Budget – это степень невыполнения наших SLO. Например, если наш SLO учитывает доступность, то error budget – это максимальное время, в течение которого наша система может быть недоступной без последствий для нас и нашей команды.

Google Kubernetes Engine Service Level Agreement (SLA)

Уровни SLI/SLO/SLA для Kubernetes, руководство от компании Google: https://cloud.google.com/kubernetes-engine/sla

Alerting on SLOs

Рекомендации по алертам: https://sre.google/workbook/alerting-on-slos/

SLI, SLA, SLO, Error, Budget, devops, уровни обслуживания, показатели, качество, качества, право на ошибку

DevOps: Tmux

anonymous@undisclosed.example.com (Anonymous) — Tue, 02 Jan 2024 10:47:31 +0000

DevOps: Tmux

Главная ссылка: https://github.com/tmux/tmux/wiki

Tmux - это один из мультиплексоров терминальных подключений, имеет кучу аналогов: от старого доброго screen до byobu.

Используется для комфортной работы, ведь в случае отключения все открытые сеансы по-прежнему работают и доступны для переподключения. Если нужно работать через откровенно плохие или тормозные каналы - можно использовать в комплекте с mosh https://mosh.org/, вот отличная обзорная статья: https://habr.com/ru/companies/vdsina/articles/472746/

Я работал по откровенно фиговому соединению с дачи, где связь была откровенно неустойчивой, да еще и пинг временами прыгал до 2000-3000 мс и в целом справлялся. Никому такого не пожелаю, но в экстренных случаях вполне себе норм.

Несмотря на годы использования tmux я так и не знаю всех (или хотя бы бОльшей части) стандартных сочетаний клавиш (и это кроме своих биндингов), поэтому вот полезные подсказки:

https://tmuxcheatsheet.com/

tmux, cheatsheet, подсказки, alias, bindings

DevOps: Подборка инструментов

anonymous@undisclosed.example.com (Anonymous) — Sun, 14 Dec 2025 10:49:00 +0000

DevOps: Подборка инструментов

Небольшая подборка полезностей для DevOps/SRE/Sysadmin.

Обновление всего на свете

https://github.com/r-darwish/topgrade - скрипт для поиска и установки обновлений. Сам topgrade работает одинаково хорошо как на линуксах, так и на маках. Запуск команды без параметров - и у вас обновлено всё, что вообще может требовать обновлений: от разных xcode до cargo, npm, gems, pip. Работает со всеми менеджерами пакетов brew, macports, ports, portage, dnf, apt, nix, pacman, aur, zypper, flatpack, snap, проверит обновления баз manpages, tldr, metasploit, плагинов tmux, zsh, fish, vim, micro, обновит все шрифты, контейнеры, vagrant, docker и так далее.

Цветовые темы

https://terminalcolors.com/

Шрифты

Как говорится «Унитаз - лицо хозяйки», но если много работаешь в консоли - становится важным удобство этой самой консоли и, самое главное - шрифтов в ней.

Мне нравятся: Fira Code Nerd Retina и Iosevka Extended Fixed.

https://www.codingfont.com/ - наглядный выбор шрифтов
https://www.programmingfonts.org/
https://www.nerdfonts.com/
Iosevka - https://github.com/be5invis/Iosevka
- Качаем и ставим ttf-iosevka и ttf-iosevka-fixed
- Windows - распаковали, выделили, правой кнопкой мышки, Установить
- Linux - распаковываем в ~/.local/share/fonts/ и запускаем
```
fc-cache -fv
```

Халява, сэр

Большая и обновляемая подборка бесплатных или условно-бесплатных ресурсов, на которых возможно посмотреть/потрогать какие-то технологии: https://github.com/ripienaar/free-for-dev

Онлайн-ресурсы

https://jsonlint.com - Проверка синтаксиса JSON
https://yamllint.com - Проверка синтаксиса YAML
https://codebeautify.org/yaml-validator
https://jsonformatter.org/yaml-validator
https://hcl2json.com - Конвертер JSON ↔ YAML и не только
https://regex101.com - Регулярные выражения

Docker и прочая контейнеризация

Большая подборка информации по обеспечению безопасности в Docker: https://github.com/myugan/awesome-docker-security
Lazydocker - Консольная утилита для работы с Docker. Сайт: https://github.com/jesseduffield/lazydocker
Dive - Консольная утилита для анализа Docker-образов, можно посмотреть какие слои есть и как сократить размер. Сайт: https://github.com/wagoodman/dive
DockerSlim - Консольная утилита для уменьшения размеров Docker-образов. Сайт: https://dockersl.im/
Ctop - аналог утилиты top но для Docker. Сайт: https://github.com/bcicen/ctop
Dry - консольная утилиты для управления Docker'ом. Сайт: https://github.com/moncho/dry
Grype - сканер уязвимостей в образах и файловых системах. Сайт: https://github.com/anchore/grype
Portainer - GUI-утилиты для управления Docker, Docker Swarm, Kubernetes. Сайт: https://www.portainer.io
Scopeo - утилита для работы с образами контейнеров и реджистри. Не требует установленного докера. Сайт: https://github.com/containers/skopeo

Статья о способах уменьшения размеров Docker-образов: https://itnan.ru/post.php?c=1&p=485650

Kubernetes

Огромная подборка всяких полезных утилит и инструментов для Kubernetes: https://collabnix.github.io/kubetools/

Krew - менеджер абсолютно необходимых плагинов для kubectl. Сайт: https://krew.sigs.k8s.io/, список плагинов: https://krew.sigs.k8s.io/plugins/
```
# kubectl krew list                                           
appscode/stash
ctx
doctor
grep
images
konfig
krew
ns
outdated
pod-lens
pvmigrate
resource-capacity
sql
tree
view-cert
view-secret
```
И еще много полезного тут: https://rtfm.co.ua/kubernetes-menedzher-plaginov-krew-i-poleznye-plaginy-dlya-kubectl/
k9s - Консольная утилита для работы с кластерами Kubernetes. Сайт: https://k9scli.io/
Lens - Шикарный GUI для работы с кластерами Kubernetes. Сайт: https://k8slens.dev/
Restic - Бэкапы. Сайт: https://restic.net/
Velero - Бэкапы в Kubernetes. Сайт: https://velero.io/
Stash - Бэкапы в Kubernetes. Платный, есть Free лицензия, ограниченная по функционалу. Сайт: https://stash.run/
K10 - Бэкапы в Kubernetes. Платный, есть Free лицензия на 10 нод. Сайт: https://www.kasten.io/
Pod-Reaper - удаляет зависшие поды по таймауту или в статусе Evicted. Сайт https://github.com/ptagr/pod-reaper

Анализ проблем в Kubernetes

Popeye - A Kubernetes Cluster Sanitizer. https://github.com/derailed/popeye
KubeEye aims to find various problems on Kubernetes. https://github.com/kubesphere/kubeeye
Weave Scope для мониторинга и отладки контейнеризированных приложений: https://www.weave.works/oss/scope/

Безопасность в Kubernetes

Чек-лист по безопасности: https://github.com/Vinum-Security/kubernetes-security-checklist
RBAC-tool умеет формировать RBAC-роли в Kubernetes по результатам анализа audit events, строить карту ролей и выявлять небезопасные роли: https://github.com/alcideio/rbac-tool
Инструмент для работы с JWT-токенами: https://jwt.io/

Пакетные менеджеры и CI/CD

ArgoCD - Инструмент для CD (continuous delivery) в Kubernetes. Сайт: https://argoproj.github.io/argo-cd/
Helm - Пакетный менеджер для Kubernetes. Сайт: https://helm.sh/

Источники чартов, образов и операторов

Docker Hub - крупнейший источник образов контейнеров. Сайт: https://hub.docker.com/
ArtifactHUB - крупнейший источник пакетов для Kubernetes. Сайт: https://artifacthub.io/
OperatorHub.io - крупнейший источник операторов для Kubernetes. Сайт: https://operatorhub.io/

Мониторинг

Набор Grafana dashboards и Prometheus alerts для Kubernetes - https://github.com/kubernetes-monitoring/kubernetes-mixin
15 Awesome Grafana Dashboards and Examples - https://www.containiq.com/post/grafana-dashboards-and-examples
Blackbox exporter for Prometheus - https://github.com/prometheus/blackbox_exporter
Goldpinger - Мониторинг сети нод в Kubernetes. Сайт: https://github.com/bloomberg/goldpinger
Kubenurse - мониторинг сети в Kubernetes - https://github.com/postfinance/kubenurse

Тестирование нагрузки

Yandex Tank: https://yandex.ru/dev/tank/
K6: https://k6.io/
Bombardier: https://github.com/codesenberg/bombardier

Web Application Firewall (WAF)

ModSecurity для Apache: https://github.com/SpiderLabs/ModSecurity
NAXSI для Nginx: https://github.com/nbs-system/naxsi
Nemesida WAF Free: https://github.com/nemesida-waf/nemesida_waf_free и https://github.com/nemesida-waf/waf-bypass
Vulture: https://www.vultureproject.org/

Безопасность

T-Pot - The All In One Honeypot Platform: https://github.com/telekom-security/tpotce
Chameleon - 19 Customizable honeypots for monitoring network traffic, bots activities, and username\password credentials (DNS, HTTP Proxy, HTTP, HTTPS, SSH, POP3, IMAP, STMP, RDP, VNC, SMB, SOCKS5, Redis, TELNET, Postgres, MySQL, MSSQL, Elastic and ldap): https://github.com/qeeqbox/chameleon

Тестирование скорости отдачи сайта

https://gtmetrix.com - Анализ скорости загрузки сайта, по итогам дает рекомендации

Тестирование серверов на попугаи

Для понимания хорош ли текущий VPS/хостинг и все такое

Yet-Another-Bench-Script: https://github.com/masonr/yet-another-bench-script

curl -sL yabs.sh | bash

or

wget -qO- yabs.sh | bash

Утилиты для работы с HTTP/HTTPS/API

HTTPIe - https://httpie.io
Curlie - https://curlie.io

Windows

PowerShell kubectl autocomplete - https://www.powershellgallery.com/packages/PSKubectlCompletion/

Install-Module -Name PSKubectlCompletion
Import-Module -Name PSKubectlCompletion
Register-KubectlCompletion

Сети

Сертификаты

Замена утилит командной строки keytool и jarsigner в Java для работы с сертификатами- https://keystore-explorer.org

Конвертеры

Часто бывает нужно максимально точно перевести мегабайты в мебибиты, супер-конвертер поможет: https://www.unitjuggler.com/memory-конвертация.html , Альтернативный вариант - поставить утилиту units, она есть во всех распространенных дистрибутивах.

DevOps: Графическая оболочка за несколько секунд

anonymous@undisclosed.example.com (Anonymous) — Sat, 28 Oct 2023 14:46:05 +0000

DevOps: Графическая оболочка за несколько секунд

Бывает так, что требуется графическая оболочка во прямо здесь и сейчас. Можно поднять отдельную виртуалку с ОС, можно воспользоваться LiveCD любого дистрибутива, а можно поднять контейнер с любым из дистрибутивов Webtop. Несколько секунд ожидания на загрузку образа docker'а и можно подключаться. Работает такой рабочий стол через браузер, довольно быстр и потребляет весьма немного ресурсов.

Домашняя страничка проекта: https://github.com/linuxserver/docker-webtop

linux, webtop, container, livecd, desktop environment, docker, devops tools

DevOps: Инструменты на Windows 10

anonymous@undisclosed.example.com (Anonymous) — Thu, 26 Aug 2021 20:12:11 +0000

DevOps: Инструменты на Windows 10

Если есть желание/необходимость девопсить на Windows 10 - ниже небольшая инструкция.

Установка WSL 2

Можно через стандартные «Программы и компоненты» → «Установка компонентов Windows», выбрать «Windows Subsystem for Linux» или через команды:

Powershell:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

cmd:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Далее согласно инструкции https://aka.ms/wsl2kernel загружаем и устанавливаем пакет https://aka.ms/wsl2kernelmsix64

Переключаем на использование второй версии WSL

wsl --set-default-version 2

Если уже что-то работало под WSL, можно сконвертировать:

wsl.exe -l
wsl.exe --set-version Ubuntu-20.04 2
wsl.exe --set-version Debian 2

Так же есть экспорт/импорт:

wsl.exe --export Ubuntu-20.04 C:\temp\ubuntu2004.tar
wsl.exe --import ubuntu2004 C:\wsl c:\temp\ubuntu2004.tar
wsl --list --all
wslconfig /list /all
wsl --setdefault ubuntu2004
wsl --distribution ubuntu2004
cd \\wsl$\ubuntu2004
wsl --shutdown

Установка Linux

Устанавливаем необходимую версию Linux с сайта Microsoft Store https://aka.ms/wslstore

Устанавливаем терминал (опционально)

Можно установить Windows Terminal https://aka.ms/terminal или Fluent Terminal https://github.com/felixse/FluentTerminal - кому что нравится и работать прямо из Windows. А можно прямо из Linux.

Настройка WSL 2

Время в WSL может отличаться от времени на Windows, эта команда его синхронизирует:

sudo hwclock --hctosys

windows, 10, wsl, wsl2, ubuntu, linux, windows terminal, fluent terminal, zsh

DevOps: Шаблон Post Mortem

anonymous@undisclosed.example.com (Anonymous) — Tue, 03 Oct 2023 19:19:07 +0000

DevOps: Шаблон Post Mortem

https://incident.io/blog/incident-post-mortem-template

Key information

The key information section is a recap of the data behind the incident. It’s the most succinct summary of the incident, which is useful to orient anyone reading the remainder of the document.

Think of this as the metadata of your incident. Core information such as incident type, severity, leads and more should be outlined here.

Here’s what this section could look like:

ℹ️ Tagged Data!
    Incident Type: Platform
    Severity: Major
    Affected services: Login, Cart, User Preferences

👪 Team
    Incident Lead: Chris Evans
    Reporter: Steven Millhouse
    Active participants: Rebecca Song
    Observers: Michael Scott

🔗 Useful Links
    Jira issue
    Slack channel

⏱️ Key Timestamps
    Impact started at: November 10, 2022 2:12 PM
    Reported at: November 10, 2022 2:12 PM
    Identified at: November 10, 2022 2:18 PM
    Fixed at: @November 10, 2022 2:20 PM (UTC)
    Closed at: November 10, 2022 2:30 PM

Incident summary

The summary should be a concise and accessible overview of the incident. It’s important that this summary is exactly that, a summary. If you try to throw everything in here, it becomes very difficult for someone to come in later on and easily parse what happened.

Your incident summary should clearly articulate what happened, who was involved, how you responded, and the overall impact of the event. It’s helpful for the summary to be written such that someone who wasn’t there can use it to develop a high-level understanding of the situation.

We find it useful to pitch it so your boss’s boss would understand!

Here’s a real-life incident post-mortem summary we wrote up internally:

💡 On 2022-11-18 from 15:39 to approximately 16:23, an asynchronous event caused an error which took one of our Heroku "dynos" down (referred to as servers for simplicity below). Our infrastructure logic is such that if an event has an issue being processed, it retries. In this case, it meant that another server then attempted to process the same malformed/dangerous event, before also crashing. This repeated until all our servers were down, at which point our app became completely unavailable. This type of error is commonly known as a "poison pill".

The poison pill was caused by a consumer that returned an error, which wrapped a nil error. This meant our consumer tried to unwrap the error and got a nil pointer dereference when trying to access the root cause. Normally this would be fine, however only the actual app-code section of our queue consumers were within the panic recovery boundary, so by panicking in the pubsub wrapper, we'd crash the entire app.

We quickly rebooted the servers, but unfortunately, the event was retried again, taking down each server in quick succession after a few minutes. This continued for around 25 minutes.

We deployed a fix to make sure all of the code in our consumers were covered by a "recover" statement (meaning we handle errors like this more gracefully), which then quickly caught the error once we deployed it and also prevented it taking the app down again.

From there, we fixed the bad code and stayed online. We also made a number of other improvements to our app and infrastructure setup.

Incident timeline

The incident timeline exists to provide a narrative of the incident; essentially retelling the story from start to finish. It should outline key events and developments that took place, investigations that were carried out, and any actions that were taken.

It’s tempting to go into huge amounts of detail here, but we’d typically advise the detail to remain in an incident communication thread (i.e. a Slack channel), and have the timeline contain just the significant events and developments.

Typically we’d include the timestamp (in the dominant timezone for the incident or UTC if spanning many), the time since the notional start of the incident, as well as any details about what was happening.

Timestamp 	Event
12:00:00 	Chris reported the incident
12:07:00 (+7mins) 	Incident lead assigned
12:10:00 (+10mins) 	Issue identified
12:12:00 (+12mins) 	Incident closed

Contributors

We think it’s helpful to enumerate the contributors of an incident, where contributors are thought of not as ‘root causes’ but as a collection of things that had to be true for this incident to take place, or that contributed to its severity.

This can include technical contributors (e.g. the server’s disk filled up), human contributors (e.g. the on-call engineer did not respond the first time we paged them), and any other external contributors (e.g. we were simultaneously running a marketing event).

It’s useful to enumerate these items to fully explore the space of the problem, and avoid overly fixating on a singular cause.

Mitigators

Where contributors constitute the set of things that helped the incident occur, mitigators can be thought of as the opposite. More precisely, they’re anything that helped to reduce the overall impact of the event.

Like contributors these can come in many guises, like the incident happened during working hours, or the fact that the person who knows the most about the system at the heart of the incident also being on call.

It’s useful to explicitly call these out, as they often highlight positive capacities that are helpful to double down on, or socialize further.

Learnings and risks

This section is a little harder to capture, but it should answer questions like: what did we learn, how can we streamline our response in the future, and what broader risks did this incident point towards?

For example, you might have learned that one of your teammates was the only person who knew the details of the system that failed during this incident, and that might point at a more general “key person risk.” If other incidents point at similar risks, that’s useful learning for teams.

Follow-up actions

Follow-up actions are here to convey what’s being done to reduce the likelihood and/or impact of similar events in future.

In the context of this document, we think it’s most useful to highlight any key actions items or deliverables, rather than the full set. Ultimately, this will vary depending on the intended audience, but if the document is being written to be read and learned from, this section should close the loop on what’s being done to mitigate the major themes that have been identified.

Optional: Post-mortem meeting notes

Many post-mortems can happen async but others may require a dedicated meeting to talk through what happened—especially incidents that were of higher severity. In cases like these, it’s a good idea to set up some time with incident response team members and relevant stakeholders and use the post-mortem as your meeting agenda.

While it may seem a bit redundant, having the space to have a retrospective and talk through issues in real-time ultimately encourages better team collaboration and communication that’s nearly impossible to capture over an async document.

It’s a good idea to brainstorm and collect talking points to help guide your post-mortem analysis meeting. In the end, an effective-post mortem meeting ensures that your team is rallying around tactics that will drive continuous improvement of your response processes and ultimately your product.

post-mortem

DevOps: Monitoring Cheat Sheet

anonymous@undisclosed.example.com (Anonymous) — Sat, 16 Sep 2023 10:04:48 +0000

DevOps: Monitoring Cheat Sheet

Актуально на сентябрь 2023 года

Взято тут: https://blog.bytebytego.com и там еще много вкусного

мониторинг, monitoring, cheat, sheet

Nala: apt со стероидами

anonymous@undisclosed.example.com (Anonymous) — Wed, 02 Aug 2023 10:25:44 +0000

Nala: apt со стероидами

Apt это, без сомнения, отличный пакетный менеджер, но всегда хочется чего-нибудь лучше и интереснее. Если так - то Nala это ваш выбор.

Зачем еще один пакетный менеджер? Nala это надстройка над libapt-pkg, из плюсов:

Первое и главное для меня - понятная подача информации об обновлении, цветом выделены изменения. Не нужно вглядываться в портянку.
Функция «History» - упрощает понимание что и как менялось в системе
Параллельная загрузка пакетов, реально обновление происходит быстрее. Да, можно использовать сторонний apt-fast но тут оно прикручено по умолчанию и является одной из фишек
Тестирование зеркал для выбора самого быстрого

Минусы:

Требует python 3.10 и выше, если ставим на 20.04 это нужно иметь в виду
Иногда странно притормаживает, но не больше обычного apt

Домашняя страница: https://gitlab.com/volian/nala

Установка в Ubuntu 22.04 и выше делается просто:

# sudo apt install nala -y

Для более старых версий нужно читать инструкцию: https://gitlab.com/volian/nala/-/wikis/Installation

Далее включаем подсказки:

nala --install-completion

Команды идентичны apt, при желании можно сделать такой alias для обхода приглашения sudo:

apt() { 
  command nala "$@"
}
sudo() {
  if [ "$1" = "apt" ]; then
    shift
    command sudo nala "$@"
  else
    command sudo "$@"
  fi
}

Установка пакетов:

sudo nala install ansible

История:

nala history

Можно откатываться по истории командами undo и redo, в качестве параметра используем ID записи из истории. Например:

sudo nala history undo 2

Стоит ли установить и пользоваться? Как для меня, так однозначно да.

Teamlead Roadmap

anonymous@undisclosed.example.com (Anonymous) — Sun, 13 Feb 2022 08:35:45 +0000

Teamlead Roadmap

Ресурсы с роадмапами для тимлида:

Карта навыков и компетенций тимлидов, которую можно адаптировать для любой компании и команды - https://tlroadmap.io/
Вантуван 1:1 - https://tlroadmap.io/roles/people-manager/people-management/one-on-one.html
Карта навыков и компетенций тимлидов - https://github.com/tlbootcamp/tlroadmap

teamlead, roadmap, навыки, компетенции, роадмап, 1

Установка Zsh и Oh My Zsh!

anonymous@undisclosed.example.com (Anonymous) — Wed, 29 Nov 2023 09:27:13 +0000

Установка Zsh и Oh My Zsh!

Установка Zsh

sudo apt install zsh

Установка Oh My Zsh

Выбираем удобный вариант, в зависимости от установленного в системе ПО:

# Curl
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
# Wget
sh -c "$(wget https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh -O -)"

Установка Zsh оболочкой по умолчанию

Достаточно выполнить команду для текущего пользователя:

chsh -s $(which zsh)

Настройка темы оформления

Для включения популярной темы agnoster нужно открыть файл ~/.zshrc, найти строку ZSH_THEME=«robbyrussell» и заменить стандартную тему на нужную, в моем случае agnoster, итого получается ZSH_THEME=«agnoster». Не забываем про

source ~/.zshrc

Примечание: если при смене темы получаем уведомление «zsh | (anon):12: character not in range» - это значит что в системе нет поддержки локали en_US.UTF-8

Лечится довольно просто, но зависит от текущей установленной системы.

1-й способ (debian container):

Добавляем в /etc/locale.gen строку 'en_US.UTF-8 UTF-8'
Запускаем
```
locale-gen
```

2-й способ (если в системе вообще нет пакета):

Ставим пакет и обновляем локали:
```
apt-get install -y language-pack-en && update-locale
```

Если хочется чего-то иного, можно найти много тем на любой вкус:

Официальные: https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
Дополнительные: https://github.com/ohmyzsh/ohmyzsh/wiki/External-themes

На вкус и цвет все разные, но самые удобные на мой взгляд это agnoster, powerlevel10k

Установка powerlevel10k:

git clone https://github.com/romkatv/powerlevel10k.git $ZSH_CUSTOM/themes/powerlevel10k

Изменить тему:

ZSH_THEME="powerlevel10k/powerlevel10k"

Конфигурация:

p10k configure

Установка шрифтов

Если нет иконок Git или нету «уголков» в строке навигации, то вам нужно поставить дополнительные шрифты. Большинство тем требует установки данных шрифтов, они никак не помешают, но будет работать как нужно. Если всё хорошо и косяков нет - ставить не нужно.

Примечание: Если вы работаете в Windows, шрифты так же необходимо поставить.

sudo apt install fonts-powerline

или

git clone https://github.com/powerline/fonts.git
cd fonts
./install.sh
cd ..
rm -rf fonts

Устанавливаем цветовую палитру для терминала

Мне нравится solarized:

git clone git://github.com/sigurdga/gnome-terminal-colors-solarized.git ~/.solarized
cd ~/.solarized
./install.sh

Выбираем пункт 1 (dark theme). Затем выбираем 1 для загрузки dircolors-solarized. После установки редактируем .zshrc и добавляем строку:

eval `dircolors ~/.dir_colors/dircolors`

Полезные плагины

Основной сайт с плагинами: https://github.com/ohmyzsh/ohmyzsh/wiki/Plugins

И еще много всего тут: https://github.com/unixorn/awesome-zsh-plugins

Как может выглядеть секция с подключенными плагинами:

plugins=(
    git
    colored-man-pages
    docker
    ansible
    zsh-autosuggestions
    kubectl
)

kubectl

Источник: https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion

Добавляем строку в файл .zshrc:

source <(kubectl completion zsh)

Если нужен алиас для команды kubectl, добавляем:

echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc

zsh-autosuggestions

Работает с историей zsh, очень полезно если периодически набираем длинные команды.

Сайт: https://github.com/zsh-users/zsh-autosuggestions

Установка:

Клонируем репозиторий в $ZSH_CUSTOM/plugins (по умолчанию ~/.oh-my-zsh/custom/plugins):

git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Добавляем в файл конфигурации ~/.zshrc:
```
plugins=(zsh-autosuggestions)
```
и перезапускаем сессию

fast-syntax-highlighting

Раскрашивает синтаксис

Сайт: https://github.com/zdharma-continuum/fast-syntax-highlighting

Установка:

Клонируем репозиторий

git clone https://github.com/zdharma-continuum/fast-syntax-highlighting.git \
  ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/fast-syntax-highlighting

Добавляем в файл конфигурации ~/.zshrc:
```
plugins=(fast-syntax-highlighting)
```
и перезапускаем сессию

fzf-tab

Нечеткий поиск по всему: от истории до каталогов и ключей командной строки для утилит.

Сайт: https://github.com/Aloxaf/fzf-tab

Примечания к установке:

Должен быть обязательно установлен оригинальный fzf
С списке плагинов fzf-tab должен быть ДО zsh-autosuggestions или fast-syntax-highlighting

Установка:

Клонируем репозиторий

git clone https://github.com/Aloxaf/fzf-tab ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/fzf-tab

Добавляем в файл конфигурации ~/.zshrc:
```
plugins=(fzf-tab)
```
и перезапускаем сессию

Использование: как обычно нажимаем Tab при вводе команд и аргументов

fzf

Еще один вариант расширенного поиска по истории, не стоит использовать совместно с fzf-tab

Сайт: https://github.com/junegunn/fzf

Установка:

Клонируем репозиторий

git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf; ~/.fzf/install

Отвечаем на вопросы

Настройки Zsh

Все настройки хранятся в файле ~/.zshrc

Удаляем Zsh и Oh My Zsh

uninstall_oh_my_zsh
sudo apt uninstall zsh

zsh, oh, my, zsh