Это похоже на то, как поднимаешься в гору. Неопытные люди часто рвутся и… сдыхают. Чуть-чуть отдохнул, опять рванулся и опять умер. И так далее. Опытные люди идут равномерно. Пусть сначала медленно, но равномерно. И так можно подняться на гору без особых проблем. Особенно чётко эта разница видна на высоте, когда начинает сказываться нехватка воздуха.
То же самое верно про бег на дальние дистанции. У человека есть быстрые и медленные мышечные волокна, которые работают соответственно на углеводах и жирах. Быстрые дают большую мощность, но не больше минуты, а дальше закисляются и перестают работать. Если бежишь марафон, то важны медленные мышечные волокна.
Как вышенаписанное применить в режиме челленджа? Сделать челлендж плановым. Так скоро, насколько возможно. Пусть я буду работать по 12 часов и спать по 5 часов в день. Но это будет по плану. И отдыхать по плану. И тогда всё будет в порядке. Жизненный опыт показывает, что так и будет.
Преимущество терраформа перед ансиблом, шефом и тп для инфраструктуры — состояние, что позволяет управлять полным жизненным циклом обьекта, а не только созданием.
В моём случае другой подход: управляем тем, что записано в конфиге.
Репа есть в конфиге? Она управляется.
Нет в конфиге? С репой гарантированно ничего не случится.
Некоторые операции у меня не реализованы. Например, удалить репу невозможно. Но это никогда не требовалось. И так даже лучше, не получится случайно отстрелить себе ногу.
А если сархивировать репу, то её и Terraform не сможет разархивировать обратно.
С одной стороны, это просто сделать. С другой стороны, за год эксплуатации у нас не было ничего подобного. Тогда зачем исправлять проблему, которая никогда не возникнет?
Управляя Github-ом: через Terraform к самописному решению на Ansible
Ушли с Github-а на self-hosted Gitlab.
Субъективный взгляд на выгорание: как начать подгорать, но не выгореть
Это похоже на то, как поднимаешься в гору. Неопытные люди часто рвутся и… сдыхают. Чуть-чуть отдохнул, опять рванулся и опять умер. И так далее. Опытные люди идут равномерно. Пусть сначала медленно, но равномерно. И так можно подняться на гору без особых проблем. Особенно чётко эта разница видна на высоте, когда начинает сказываться нехватка воздуха.
То же самое верно про бег на дальние дистанции. У человека есть быстрые и медленные мышечные волокна, которые работают соответственно на углеводах и жирах. Быстрые дают большую мощность, но не больше минуты, а дальше закисляются и перестают работать. Если бежишь марафон, то важны медленные мышечные волокна.
Как вышенаписанное применить в режиме челленджа? Сделать челлендж плановым. Так скоро, насколько возможно. Пусть я буду работать по 12 часов и спать по 5 часов в день. Но это будет по плану. И отдыхать по плану. И тогда всё будет в порядке. Жизненный опыт показывает, что так и будет.
Управляя Github-ом: через Terraform к самописному решению на Ansible
Управляя Github-ом: через Terraform к самописному решению на Ansible
В моём случае другой подход: управляем тем, что записано в конфиге.
Некоторые операции у меня не реализованы. Например, удалить репу невозможно. Но это никогда не требовалось. И так даже лучше, не получится случайно отстрелить себе ногу.
А если сархивировать репу, то её и Terraform не сможет разархивировать обратно.
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
Добавил в P.S. ссылку на репу с кодом: https://github.com/igmp/lets-use-ssl.
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
Vault тоже юзаем. Можно было бы и там хранить.
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
docs.ansible.com/ansible/latest/modules/route53_module.html
Если бы DNS жил в Гугле, то использовалась бы эта штука:
docs.ansible.com/ansible/latest/modules/gcdns_record_module.html
А для PowerDNS есть масса вариантов.
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
С одной стороны, это просто сделать. С другой стороны, за год эксплуатации у нас не было ничего подобного. Тогда зачем исправлять проблему, которая никогда не возникнет?
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению
Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению