Erro em login administrativo no Tsuru 1.7.0-rc1 imediatamente após instalação

[fititnt]

Nosso primeiro produto mínimo viável usando apenas um servidor remoto com tudo instalado a Charlie fititnt/cplp-aiops#58 com o Tsuru 1.6.0 stable fititnt/cplp-aiops#59 funcionou muito bem. Só não foi de primeira tentativa porque sem parâmetros ele tentaria instalar em virtualbox local.

Dessa vez sem usar a versão stable, mas sim a tsuru version 1.7.0-rc1 temos alguns erros.

# O comando a seguir cria o primeiro usuario. Vou usar meu e-mail, mas você
# deveria usar o seu. Ele vai pedir senha e reconfirmação
tsuru user-create [email protected]
# Resultado:
#  Password:
#  Confirm:
#  User "[email protected]" successfully created!

# O próximo comando é para se logar no Tsuru remoto padrão (no caso temos apenas
# um, a Charlie movi para outra pasta no meu ~/.tsuru). O comando 'tsuru login'
# Também pode aceitar o e-mail como parâmetro, mas vou usar sem nesse momento
tsuru login
# Resultado
#   Email: [email protected]
#   Password:
#   Successfully logged in!

# Vamos ver se já existe algum time criado
tsuru team-list
# Resposta: vazio (não tem times existentes)

# Conforme documentação, seria necessario criar um time, porém tenho erro sem
# informação extra além de 'Error:'
tsuru team-create EticaAI
# Resultado
#   Error:

# E sim, também estou documentando meu passo a passo porque pode servir para
# reportar depois para o time do Tsuru o que pode ser melhorado na documentação
# da versão atual

# Tentando dar permissão total para meu usuário, talvez seja isso que esteja
# impedindo seguir adiante.
tsuru role-assign AllowAll [email protected]
# Error: You don't have permission to do this action

# Humm... isso funcionou com a Charlie em https://github.com/fititnt/cplp-aiops/blob/master/logbook/aguia-pescadora-charlie.sh
# porém a versão do Tsuru era a stable 1.6.0. A atual 1.7.0-rc1.

O log completo de instalação está neste arquivo: https://github.com/EticaAI/aguia-pescadora/blob/master/diario-de-bordo/tsuru-inicializacao/tsuru-inicializacao.log.

O arquivo usado na configuração de inicialização do cluster está em https://github.com/EticaAI/aguia-pescadora/blob/master/diario-de-bordo/tsuru-inicializacao/config.yml

[fititnt]

Ah!. ok, tem uma diferença entre a nossa instalação em fititnt/cplp-aiops#59 (comment) e o arquivo a primeira tentativa em https://github.com/EticaAI/aguia-pescadora/blob/master/diario-de-bordo/tsuru-inicializacao/tsuru-inicializacao.log.

Que o log de instalação do Tsuru deu um erro logo de primeira, eu vi. Porém uma das diferenças grandes para o 1.6.0 (que não teve qualquer erro) é que no 1.6.0 na Charlie, em um determinado momento, ele começou a criar a API:

aguia-pescadora-charlie.etica.ai (Tsuru 1 node)

(...)
Deploying compose file in cluster manager....
Creating network tsuru_tsuru
Creating service tsuru_redis
Creating service tsuru_mongo
Creating service tsuru_planb
Creating service tsuru_registry
Creating service tsuru_tsuru
Restarting docker in aguia-pescadora-1
Waiting for SSH to be available...
Detecting the provisioner...
Waiting for Tsuru API to become responsive...
�+Opening config file: /etc/tsuru/tsuru.conf
�0Done reading config file: /etc/tsuru/tsuru.conf
�OWarning: configuration didn't declare a database driver, using default driver.
�@Using "mongodb" database "tsuru" from the server "mongo:27017".
�
Password: �

Confirm: ��
� Root user successfully created.
Bootstrapping Tsuru API...adding target
New target aguia-pescadora -> http://192.99.69.2:8080 added to target list and defined as the current target
log in with default user: [email protected] Password: 
Successfully logged in!
adding pool
Pool successfully registered.
adding node https://192.99.69.2:2376
Node successfully registered.
adding platform
Step 1/1 : FROM tsuru/python
latest: Pulling from tsuru/python
898c46f3b1a1: Pull complete 
63366dfa0a50: Pull complete 



(...)



---- Setting router healthcheck (Path: /) ----

OK
Applying iptables workaround for docker 1.12...
Failed to apply iptables rule: ssh command error:
command : PATH=$PATH:/usr/sbin/:/usr/local/sbin; sudo iptables -D DOCKER-ISOLATION -i docker_gwbridge -o docker0 -j DROP
err     : exit status 1
output  : iptables: Bad rule (does a matching rule exist in that chain?).
. Maybe it is not needed anymore?
Failed to apply iptables rule: ssh command error:
command : PATH=$PATH:/usr/sbin/:/usr/local/sbin; sudo iptables -D DOCKER-ISOLATION -i docker0 -o docker_gwbridge -j DROP
err     : exit status 1
output  : iptables: Bad rule (does a matching rule exist in that chain?).
. Maybe it is not needed anymore?
--- Installation Overview ---
Core Hosts:
+-------------+-------+---------+
| IP          | State | Manager |
+-------------+-------+---------+
| 192.99.69.2 | ready | true    |
+-------------+-------+---------+

Core Components:
+----------------+-------+----------+
| Component      | Ports | Replicas |
+----------------+-------+----------+
| tsuru_planb    | 80    | 1        |
+----------------+-------+----------+
| tsuru_registry | 5000  | 1        |
+----------------+-------+----------+
| tsuru_tsuru    | 8080  | 1        |
+----------------+-------+----------+
| tsuru_mongo    |       | 1        |
+----------------+-------+----------+
| tsuru_redis    |       | 1        |
+----------------+-------+----------+
Configured default user:
Username: [email protected]
Password: admin123
Apps Hosts:
+--------------------------+---------+--------+----------------------------------+
| Address                  | IaaS ID | Status | Metadata                         |
+--------------------------+---------+--------+----------------------------------+
| https://192.99.69.2:2376 |         | ready  | LastSuccess=2019-06-03T03:01:52Z |
|                          |         |        | pool=theonepool                  |
+--------------------------+---------+--------+----------------------------------+
Apps:
+-----------------+------------+------------------------------------+
| Application     | Units      | Address                            |
+-----------------+------------+------------------------------------+
| tsuru-dashboard | 1 starting | tsuru-dashboard.192.99.69.2.nip.io |
+-----------------+------------+------------------------------------+

aguia-pescadora-{bravo,echo-foxtrot}.etica.ai (Tsuru 3 node)

Já na nossa nova versão em https://github.com/EticaAI/aguia-pescadora/blob/master/diario-de-bordo/tsuru-inicializacao/tsuru-inicializacao.log, temos algo diferente. A instalação pode simplesmente ter falhado no meio. Humm....

Deploying compose file in cluster manager....
Creating network tsuru_tsuru
Creating service tsuru_planb
Creating service tsuru_registry
Creating service tsuru_tsuru
Creating service tsuru_redis
Creating service tsuru_mongo
Restarting docker in aguia-pescadora-1
Waiting for SSH to be available...
Detecting the provisioner...
Waiting for Tsuru API to become responsive...
�+Opening config file: /etc/tsuru/tsuru.conf
��Done reading config file: /etc/tsuru/tsuru.conf
Warning: configuration didn't declare a database driver, using default driver.
Using "mongodb" database "tsuru" from the server "mongo:27017".
�
Password: �

Confirm: ��
� Root user successfully created.
Bootstrapping Tsuru API...Running pre-create checks...
Creating machine...
(aguia-pescadora-2) Importing SSH key...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...


(...)

Uploading registry certificate...
adding target
New target aguia-pescadora -> http://173.249.10.99:8080 added to target list and defined as the current target
log in with default user: [email protected] Password: 
Successfully logged in!
adding pool
Pool successfully registered.
adding node https://173.249.10.99:2376
Node successfully registered.
adding node https://167.86.127.220:2376
Node successfully registered.
adding node https://173.249.10.99:2376
Error: Error bootstrapping tsuru: failed to register node: Node address shouldn't repeat

Se for isso mesmo talvez seja melhor simplesmente recomeçar corrigindo arquivo de configuração do que tentar forçar funcionar. Vou ver o que faço.

[fititnt]

Aqui apenas referência das imagens da primeira execução. Talvez eu anexe elas (ou a tentativa que der certo de primeira) na documentação do #5.

Acho que eu achei especialmente interessante é que durante toda instalação o Tsuru não passou do uso de 315MB de RAM no nó mestre.

Inicio

Meio

Fim

[fititnt]

A Foxtrot parece que nem mesmo teve docker instalado.

Outra coisa estranha é que, pelo que me lembro quando testei a Charlie, o tsuru client tinha instalado ela com hostname 'aguia-pescadora-1' e ao que parece, ele instalou a Delta com hostname 'aguia-pescadora-2', então talvez apenas renomear o diretorio '~/.tsuru' e reusar o nome 'agua-pescadora' pro cluster pode ter feito o tsuru client ter guardado algum cache anterior.

Outro ponto é que talvez eu precise remover completamente o tsuru dos servidores remotos para poder retestar tudo.

Delta

Last login: Wed Jun 19 23:05:25 2019 from 201.21.106.135
root@aguia-pescadora-2:~# docker ps
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS               NAMES
6c7d1a3dc9e4        tsuru/planb:latest   "/bin/planb --listen…"   3 hours ago         Up 3 hours          8080/tcp            tsuru_planb.1.rdc4s6r85bha5wzg1m0nhjbkm
64917ea2f63a        mongo:latest         "docker-entrypoint.s…"   3 hours ago         Up 3 hours          27017/tcp           tsuru_mongo.1.mnq6q2rbxt37pxwzkya8tm1sr
0768d7688055        redis:latest         "docker-entrypoint.s…"   3 hours ago         Up 3 hours          6379/tcp            tsuru_redis.1.gic9zz9id2l4o4khl41n4vazg
92ec3e9bc51f        tsuru/api:v1         "/bin/tsurud api"        3 hours ago         Up 3 hours          8080/tcp            tsuru_tsuru.1.v0iqhtjuolvup1urq17uwwnp7
3171d2ff8a58        registry:2           "/entrypoint.sh /etc…"   3 hours ago         Up 3 hours          5000/tcp            tsuru_registry.1.rp673612fo2bxhf0rkdsi2ys1
root@aguia-pescadora-2:~# 

Echo

# fititnt at bravo in /alligo/code/eticaai/aguia-pescadora/diario-de-bordo/tsuru-inicializacao on git:master o [23:22:12]
$ ssh [email protected] 
Last login: Thu Jun 20 02:04:41 2019 from 201.21.106.135
root@aguia-pescadora-3:~# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
root@aguia-pescadora-3:~# 

Foxtrot

Last login: Wed Jun 19 23:00:33 2019 from 201.21.106.135
root@aguia-pescadora-foxtrot:~# docker

Command 'docker' not found, but can be installed with:

apt install docker.io

root@aguia-pescadora-foxtrot:~# 

[fititnt]

Comando tsuru install-remove não funciona

# fititnt at bravo in /alligo/code/eticaai/aguia-pescadora/diario-de-bordo/tsuru-inicializacao on git:master o [0:06:21]
$ tsuru install-remove 
Unable to fetch installed hosts.
Falling back to configuration file.
The following core machines will be destroyed:
+------+----+------+
| Name | IP | Data |
+------+----+------+
Are you sure you sure you want to uninstall tsuru? (y/n) y
Are you really sure? I wont ask you again. (y/n) y
Core Machines successfully removed!
removing target
Uninstall finished successfully!

[fititnt]

Ok. Descobri parcialmente o erro. A sintaxe de por no config.yml no caso de ter mais nós é diferente da que eu estava testando, então o #7 talvez seja desnecessário, embora eu talvez acabe testando um pouco mais ou nele ou no 1.7 até realmente decidir qual versão de Tsuru a gente use.

No nosso caso, o interesse seria deixar o core no tsuru na Delta (e apenas nela) mas não deixar de usar ela também para ter alguns apps. Porém enquanto no caso de usar apenas 1 nó parece dar para repitir os valores em hosts:core e hosts:apps, ao usar mais de um nó, isso gera um erro.

Provavelmente depois de já ter criado um cluster é possivel adicionar e remover tudo via linha de comando, porém eu acabe indo um pouco mais fundo antes em decidir a arquitetura (o que fica aonde) e deixar o máximo de configurações prontas para dai sim, se tivesse que reconstruir, poder ser relativamente bem rápido.

[fititnt]

Fechando esse aqui. Issue mais específico para o que causava esse problema está em #8.

O #7 talvez também seja desnecessário, porém isso fica para outro momento.