Pull to refresh
10
0
Игорь Плехов @igmp

тимлид команды, решающей проблемы разработчиков

Управляя Github-ом: через Terraform к самописному решению на Ansible

Ушли с Github-а на self-hosted Gitlab.

Субъективный взгляд на выгорание: как начать подгорать, но не выгореть

Это похоже на то, как поднимаешься в гору. Неопытные люди часто рвутся и… сдыхают. Чуть-чуть отдохнул, опять рванулся и опять умер. И так далее. Опытные люди идут равномерно. Пусть сначала медленно, но равномерно. И так можно подняться на гору без особых проблем. Особенно чётко эта разница видна на высоте, когда начинает сказываться нехватка воздуха.


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


Как вышенаписанное применить в режиме челленджа? Сделать челлендж плановым. Так скоро, насколько возможно. Пусть я буду работать по 12 часов и спать по 5 часов в день. Но это будет по плану. И отдыхать по плану. И тогда всё будет в порядке. Жизненный опыт показывает, что так и будет.

Управляя Github-ом: через Terraform к самописному решению на Ansible

  • TF мои потребности не покрывает. Подробности в статье.
  • Поставленные цели я достиг. :-) Какие они были — читайте там же.

Управляя Github-ом: через Terraform к самописному решению на Ansible

Преимущество терраформа перед ансиблом, шефом и тп для инфраструктуры — состояние, что позволяет управлять полным жизненным циклом обьекта, а не только созданием.

В моём случае другой подход: управляем тем, что записано в конфиге.


  • Репа есть в конфиге? Она управляется.
  • Нет в конфиге? С репой гарантированно ничего не случится.

Некоторые операции у меня не реализованы. Например, удалить репу невозможно. Но это никогда не требовалось. И так даже лучше, не получится случайно отстрелить себе ногу.


А если сархивировать репу, то её и Terraform не сможет разархивировать обратно.

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

Там ничего секретного нет. Будет время — выложу куда-нибудь.

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

У нас всё просто на файловой системе. Так же, как делает certbot.

Vault тоже юзаем. Можно было бы и там хранить.

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

В нашем случае DNS живёт в Route53, и для управления им используется эта штука:
docs.ansible.com/ansible/latest/modules/route53_module.html

Если бы DNS жил в Гугле, то использовалась бы эта штука:
docs.ansible.com/ansible/latest/modules/gcdns_record_module.html

А для PowerDNS есть масса вариантов.

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

Мы юзаем AWS Route53. Подойдёт любой провайдер с API.

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

Интересная идея, не думал об этом.

С одной стороны, это просто сделать. С другой стороны, за год эксплуатации у нас не было ничего подобного. Тогда зачем исправлять проблему, которая никогда не возникнет?

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

Да, для новых сервисов так и делаем. А старые остались с именами разных уровней.

Управление SSL-сертификатами: от хаоса на сотнях серверов к централизованному решению

edo1h точно отметил. У нас сертификаты используются в разных местах. В том числе таких, где нет никакого HTTP.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity