⁠Большая часть материалов этого канала берётся из моих записей, что я веду уже почти десять лет в Google Datasheets. Когда-то это начиналось просто с возможности не зависеть от ОС и используемого устройства, но со временем это вылилось в стиль работы, который особенно актуален для #devops. Хочу поделиться выработанными за годы практиками, которые, думаю, особенно будут полезны #начинающим.

Опуская способ организации документов, который может быть разным (по вкусу-привычке), остановлюсь на принципах.

Поднята новая виртуалка, которую нужно настроить (что-то сделать, просто работать и т.д.). Ей в роль (профиль) добавлены админские права, помчались.

===
Правило КОПИПАСТА. Все команды выполняем только копированием из своего документа.
===

Что это значит? Предположим, что стоит задача поднять на виртуалке Jenkins LTS в Docker. Создаю документ (я буду подразумевать гуглошиты, но это не принципиально) в папке проекта, к которому относится такая задача.

Все команды пишу сначала в документ, после просто их копирую в терминал. Речь о главных командах, относящихся к настройке — всяческие ls и отладочные не в счёт.

У меня таких документов много, всё повторяется, потому, конечно же, этого можно было бы и не делать. Да и вообще, память у меня отличная. А что не вспомню – можно быстренько нагуглить. И вообще, зачем лишние телодвижения?!? Ответ см. в п.1. (правило копипаста).

Часто (читай – всегда) нужно гуглить, нагугленное вставляю в свой документ и только из него копирую в терминал.

Мало того – сразу добавляю комментарии. Это сейчас понятно, а через месяц – нет. Комментарии выделяю, чтобы после можно было быстро видеть структуру документа, кроме того, при накоплении информации на странице, быстро ориентироваться можно будет только именно по ним.

Если есть важный ответ на команду – добавляю его. Форматирую (в моноширинный), если большой, то уменьшаю шрифт.

Выделяю важные места в ответе. Выделяю важные ключики в команде. Выделяю цветом основные параметры. Разбиваю на логические части. В общем, делаю красиво – #как_для_себя.

===

Да, это занимает время. Без практики (и начинающим) — очень много времени. Однако суть данной рекомендации в том, что #это_работает.
Уже второй подход к этой (или похожей) задаче полностью окупает потраченное время. Накопленный материал, лично переработанный, а не просто увиденный в поиске – повышает вашу квалификацию.

Во многих случаях (и с обеспечением должного уровня безопасности) в ответах команд даже можно хранить важные credentials (на картинках и постах в канале они изменены – можете не стараться :) ) – из контекста понятно для чего они и легко искать.

Удобно шарить другим. При ответственном подходе – считай, готовая документация.

А при накоплении материала – тоже сможете завести свой канал.

Но главное – это постоянное самосовершенствование. Не надейтесь на память и гугл, лишь увеличивая энтропию интернета и просмотры страниц стэковерфлоу. Упорядочивайте знания, пока они не упорядочили вас!

#recomendation #best_practices #continuous_self_improvement

⁠О вреде юзеров.

В грамотно спроектированном окружении нет (не должно быть) #IAM юзеров. Почему? Потому что у юзера есть #credentials и они должны быть где-то явно указаны (в отличие от роли, прикреплённой к инстансу).

Если у вас один аккаунт на всех и всё, значит все пользователи заходят через юзеров, что проблема в степени количества этих юзеров. Обязательно включайте MFA для всех юзеров. А лучше переходите на светлую сторону #multi_account_strategy + #SSO.

В легаси-проектах, где ПО не умеет роль (требует наличия AccessKeyId и SecretAccessKey) - приходится заводить юзера. Включайте ему минимальные права - ровно на то, что он должен делать.

Для некоторых ситуаций, например, доступ в #CodeCommit по SSH или в #ES вне #VPC - тоже требуется наличие юзера. Всё это издержки Амазона (фу, как не стыдно), не придумавшего пока, как реализовать это без юзеров.

Во всех остальных случаях - никаких юзеров. Помните, хороший юзер - это роль.

#recomendation