Comments 10
Вижу что молча минусуют. Не понимаю людей — почему не написать краткий комментарий, что не так. (я не автор статьи)
Скорее всего минусуют из-за провакционно-корявой КДПВ
Извольте. Я поставил минус. На мой взгляд, подход вполне распространённый, я сам так иногда делаю. Однако, это, простите, колхоз, и писать об этом статью как о достижении - моветон.
Идемпотентность и удалённый бутстрап - это Chef/Puppet/Salt/Ansible/etc. В зависимости от масштабов. А писать свои скрипты - это несерьёзно.
Хранить секреты в git - я этого вообще не понимаю, ну да бог вам судья, у каждого свой подход.
Я и не сомневался, что так делают многие, идея вполне очевидная и напрашивающаяся. Проблема, на мой взгляд, как раз в том, что все делают это молча, хотя возникающие в процессе сложности и подходы к их решению могут быть очевидны далеко не всем. Так что статья не "о достижении", а просто чтобы задокументировать этот подход и связанные с ним проблемы/решения.
Chef/Puppet/Salt/Ansible/etc. В зависимости от масштабов. А писать свои скрипты - это несерьёзно.
Ну я вот пытался внедрить Ansible на протяжении многих лет. Не идёт. Слишком сложно для таких масштабов, как у меня. Поэтому заставить себя не просто почитать его доку и немного поиграться, а начать использовать полноценно у меня просто не получалось. А Ansible - это лучшее из всего упомянутого.
Поэтому не вижу ничего плохого в одном тривиальном скрипте, который вполне соответствует масштабу задачи, и позволил мне таки перейти на IaC. Да, пытаться колхозить скрипт для решения этой задачи на тех масштабах, где уже нужно использовать Ansible - дурная идея. Но туда тащить этот подход я и не предлагал.
Хранить секреты в git - я этого вообще не понимаю, ну да бог вам судья, у каждого свой подход.
fnox позволяет держать секреты где угодно. Но, мне просто интересно, а где Вы предлагаете хранить секреты для пары личных серверов? И чем, на Ваш взгляд, мой вариант принципиально отличается от Ansible Vault?
Для серверов, которые нужно пересоздавать раз в 2-3 года - можно использовать что угодно, даже просто текстовый файлик со списком софта.
Проблема со своими скриптами - и я на это уже много раз натыкался сам - в том, что через эти 2-3 года внезапно обнаруживаешь, что сами скрипты устарели. Wireguard ставится из другого репозитория.. Для установки докера в старой инструкции можно было сделать add-apt-repository , а теперь нужно в keyrings писать ещё.. ssh слушает порт через systemd вместо конфига.. И скрипты надо править каждый раз, причём обнаруживаются все эти проблемы в тот момент, когда уже надо бы срочно всё восстановить..
В нормальном плейбуке все эти обновления уже отражены и плейбук "установи докер" установит его самым правильным на текущий момент способом.
Опять же - я не критикую сам подход, но хочу указать, что рекламировать нужно не его.
а где Вы предлагаете хранить секреты для пары личных серверов?
Я храню в keepass. И на серверах пишу в конфиги руками если нужно.
Мне кажется очевидным, что хранить секрет в git репозитории, даже зашифрованным, очень небезопасно. Оно же всю историю коммитов хранит. Если ключ шифрования скомпрометирован, то даже если вы его смените и перешифруете секреты - предыдущие коммиты доступны со старым ключом. Разделения доступа нет - это только для одного человека с одним ключом. Если нужно временно дать доступ только на часть секретов для коллеги - это невозможно, и отозвать доступ тоже непросто. Если репозиторий не на своём сервере, а на Github - то это вообще чужое облако.. На серверах я никогда не делаю git clone чтобы не давать доступ (даже readonly). В общем, небезопасно это всё.
Проблема со своими скриптами
Эта проблема касается только bootstrap.sh, а он минимален. Да, надо поставить докер и настроить ssh - но это плюс/минус всё, и поддерживать этот набор не сложно. Да и новые сервера в концепции "пара личных" появляются не часто. Всё это по-прежнему сильно проще, чем разбираться с Ansible (который, к слову, тоже постоянно развивается, меняется, и его конфиги скорее всего тоже через пару лет нужно адаптировать к текущей версии ансибла - так что размен такой себе).
Я храню в keepass. И на серверах пишу в конфиги руками если нужно.
Ну, свои (личные, а не которые для серверов) я тоже в Keepass держу. Но писать в конфиги сервера ручками - это ломает перевыкат сервера "одной кнопкой", разве нет? Как Вы этот подход с тем же Ansible совмещаете?
Если ключ шифрования скомпрометирован, то даже если вы его смените и перешифруете секреты - предыдущие коммиты доступны со старым ключом.
Если ключ скомпрометирован, то нужно сменить все защищённым им секреты. В любом случае, вне зависимости от того, где они хранились, и доступны ли старые коммиты - разве нет?
Разделения доступа нет - это только для одного человека с одним ключом.
Ну, технически fnox всё это умеет, и пригоден даже в enterprise. Но практически, для заявленной задачи "до 5 личных серверов" разделение доступа явно лишняя фича.
У меня на продакшене 5 серверов и сетап у них примерно как у вас - тоже есть bash-скрипт с начальными шагами. Но мне это очень не нравится, и мы планируем серьёзно это всё переделать.
Повторюсь - я сам так делаю, но считаю что это неправильно и учить такому не стоит.
Если ключ скомпрометирован, то нужно сменить все защищённым им секреты.
В общем-то да. Но кроме этого есть более простые сценарии. Например у вас украли кошелёк с флэшкой, на которой был ключ. Пока до него доберутся и поймут что это - у вас есть как минимум несколько часов, чтобы его сменить. Менять все секреты - это уж перебор. Вдобавок, ключ желательно ротировать время от времени, чтобы случайно засвеченный бэкап трёхлетней давности его не слил..
Что касается хранения секретов - это боль. Мне не нравится ни один менеджер паролей и я уже год не спеша (времени нет) пишу свой (с картами и девушками). На продакшене секреты хранятся и используются в Docker Secrets (Swarm), а чтобы их удобнее менять - у меня самописный менеджер для Swarm их умеет подменять.
Повторюсь - я сам так делаю, но считаю что это неправильно и учить такому не стоит.
Эта позиция (в отношении других вещей) мне хорошо понятна. Более того, я примерно из этих соображений несколько раз пытался освоить Ansible, да и на все альтернативы смотрел - те, которые Вы упомянули плюс ещё Terraform. И хотя я в основном всё-таки архитект и программист, но у меня хватает и админского опыта: начинал со слаквари в 94-м, в 2001 даже сделал собственный дистрибутив линуха на базе LFS и поддерживал его года 2.5 примерно, после этого перешёл на Gentoo, которым пользуюсь до сих пор. И я прекрасно понимаю всю пользу IaC. Но если при таком бэкграунде, многолетнем желании внедрить IaC, и нескольким подходам к существующим инструментам, я этого так и не сделал - возможно дело не во мне (моей лени или безграмотности), а в том, что существующие инструменты действительно не подходят для такой задачи и целевой аудитории "не профессиональный админ"?
Кроме того, даже если так делать неправильно, может всё-таки лучше так, чем никак (настраивать ручками без IaC)? У этого подхода довольно узкая область применимости - но я вроде бы честно и чётко её в статье обозначил. И если ни я ни Вы не взяли Ansible, а делаем так - почему "плохо" про это честно написать? От того, что про этот подход все будут стыдливо молчать - что изменится к лучшему? У меня вот управление серверами с ним однозначно стало лучше - IaC вполне рабочий получился, с IaC и документацией стало на порядок лучше, чем без них. Почему про это плохо рассказывать и подталкивать внедрять IaC хотя бы такими, колхозными методами?
С одной стороны, я понимаю что вы имеете в виду. Однако, "я бы мог с вами согласиться, но тогда мы бы оба оказались неправы" (с)
Для меня это выглядит как легитимизация неправильного подхода. И после прочтения может остаться желание оставить всё как есть: "смотри, другие так же делают". Однако, когда я объясняю что-то коллегам, я часто говорю "я сделал это вот так, но это НЕПРАВИЛЬНО, должно быть вот так, мы это должны переделать когда сможем", заводится таск в Jira и мозолит глаза.
Я согласен, вы в начале статьи постарались об этом предупредить, но я бы даже статью писать не стал, на вашем месте, простите. Я поставил минус, кажется, с "не согласен", но не видел смысла сильно объяснять свою позицию до тех пор, пока прохожий сеньор программист не выразил недоумение.
Ну я вот пытался внедрить Ansible на протяжении многих лет. Не идёт. Слишком сложно для таких масштабов, как у меня.
В статье говорится про 1-5 тачек - если не это идеальная возможность поработать с ansible, то что? Проще разве что из tmux панелей подключаться ко всем тачкам разом и через pane-synchronize один shell'ник, запускать
Настройка личных серверов через Docker Compose