MVP de Ansible Playbook de nó tudo-em-um do Tsuru PaaS

[fititnt]

O que comecei a testar em #25 definitivamente faz diferença no caso de um cluster mais completo e que use logo Kubernetes e não docker diretamente. Porém como já vai se ter um trabalho para documentar um cluster inteiro em https://github.com/EticaAI/aguia-pescadora-ansible-playbooks, talvez valha a pena criar uma alternatva com Ansible Playbook de implementação de um nó apenas.

Vale lembrar que já existe documentação, ainda que não testado a ponto de eu recomendar (sem ajustes extras) ser usado em produção. Vide https://github.com/EticaAI/aguia-pescadora/tree/master/diario-de-bordo/tsuru-inicializacao e https://github.com/EticaAI/aguia-pescadora/tree/master/diario-de-bordo/tsuru-inicializacao++. E uma versão mais rudimentar, porém que foi usada para testes da Charlie, ficou em fititnt/cplp-aiops#58 e fititnt/cplp-aiops#59.

No nosso caso aqui é que como possivelmente as versões mais novas de servidores podem tender a usar Ansible ou outra ferramenta, pode fazer sentido já usar isso também para uma versão mais simples.

[fititnt]

Vou ter que refatorar e quebrar em pelo menos dois roles diferentes o que agora é o role 1-node-tsuru-autossl.

O Tsuru (se instalado pela documentação recomendada, sem ser pelo kubernetes) no ansible iria precisar ser executado no localhost, enquanto a etapa de preparar o host em todos os hosts finais (que no caso é apenas 1).

O problema disso é que ao usar roles, quando um role é chamado ele já tem o alvo definido. Então a etapa de criar os arquivos de configuração do tsuru e o de invocar o tsuru install-create -c install-config.yml -e install-compose.yml precisam idealmente ser em pelo menos um role totalmente diferente.

Lembrando que talvez isso tudo seja refatorado mais na frente.

[fititnt]

Eita. Descobri que tinha sim como alternar conexão sem criar um role separado

• https://stackoverflow.com/questions/47391150/ansible-local-action-directive
• http://willthames.github.io/2018/07/01/connection-local-vs-delegate_to-localhost.html

[fititnt]

Foi. Demorou mais do que o ola mundo em fititnt/cplp-aiops#59 (comment) (e mesmo eu já sabendo como fazer diretamente) porém maior parte do tempo foi configurando o resto em Ansible.

O installer que o Tsuru Client tem por padrão é super útil.

(...)
OK
Applying iptables workaround for docker 1.12...
--- Installation Overview ---
Core Hosts:
+----------------+-------+---------+
| IP             | State | Manager |
+----------------+-------+---------+
| 167.86.127.225 | ready | true    |
+----------------+-------+---------+

Core Components:
+----------------+-------+----------+
| Component      | Ports | Replicas |
+----------------+-------+----------+
| tsuru_tsuru    | 8080  | 1        |
+----------------+-------+----------+
| tsuru_planb    | 82    | 1        |
+----------------+-------+----------+
| tsuru_mongo    |       | 1        |
+----------------+-------+----------+
| tsuru_redis    |       | 1        |
+----------------+-------+----------+
| tsuru_registry | 5000  | 1        |
+----------------+-------+----------+
Configured default user:
Username: [email protected]
Password: (REDACTED)
Apps Hosts:
+-----------------------------+---------+--------+----------------------------------+
| Address                     | IaaS ID | Status | Metadata                         |
+-----------------------------+---------+--------+----------------------------------+
| https://167.86.127.225:2376 |         | ready  | LastSuccess=2019-07-04T01:31:26Z |
|                             |         |        | pool=theonepool                  |
+-----------------------------+---------+--------+----------------------------------+
Apps:
+-----------------+------------+---------------------------------------+
| Application     | Units      | Address                               |
+-----------------+------------+---------------------------------------+
| tsuru-dashboard | 1 starting | tsuru-dashboard.167.86.127.225.nip.io |
+-----------------+------------+---------------------------------------+

[fititnt]

A versão do 2.0-alpha do águia pescadora em https://github.com/EticaAI/aguia-pescadora-ansible-playbooks na prática já contém um MVP de Tsuru, porém a 2.0.x tende a te esses pontos de melhoria (i.e. o que poderia, mas não tem, automaticamente configurado):

• Não usa Kubernetes ou K3S (o que não necessariamente é ponto negativo)
• Tsuru Gandalf (isto é, permitir por em produção usando git push em vez de tsuru app-deploy --app meuapp . )
• Tsuru MySQL As A Service (alternativa: usar MySQL via app com Docker)
• Tsuru PostgreSQL As A Service (alternativa: usar PostgreSQL via app com docker)
• Tsuru volumes

Talvez esse issue seja fechado como "sendo um MVP" e apenas no 3.0 a gente acrescente outras funcionalidades chave