Um pouco de nossa experiência tentando migrar pipelines do GoCD para Concourse-CI

Recentemente um de nossos clientes solicitou a criação de um time para que fosse feita a migração de todas as suas pipelines (que estão no GoCD) para o ConcourseCI. Não vamos entrar em detalhes dos motivos por trás dessa decisão, mas contar como foi o processo que adotamos, quais foram os desafios e por que ao final de um mês chegamos a conclusão que para o seu contexto a migração não seria recomendada.

Nota: O time que foi montado era composto por apenas três pessoas, eu, Melina Deraldo e Marco Valtas.

Nota 2: Utilizamos a versão 3.9.1, por isso alguns dos problemas que vamos descrever podem ter sido resolvidos ou melhorados nas novas versões.

O Começo

Como o tempo era bem curto para a realização dessa migração (o cliente queria ir a produção com sua nova plataforma já usando suas pipelines migradas, e isso aconteceria em mais ou menos 2 meses) e nenhum de nós havia trabalhado anteriormente com Concourse, decidimos ir o mais Lean possível e para isso criamos um board no Trello e listamos as principais atividades que deveriamos realizar, tais como:

1. Listar pipelines a serem migradas
2. Comparar os recursos do Concourse com o GoCD
3. Subir uma instância do Concourse na AWS

• Com as primeiras atividades conseguimos listar algumas das características e recursos do Concourse:

  1. No concourse tudo se baseia em conceitos de companhias aereas então temos alguns recursos que são nomeados como ATC (Air Traffic Control) que é a interfade web e scheduler de builds.
  2. Utiliza uma CLI nomeada como fly que é a responsável por rodar as builds no ATC.
  3. TUDO é executado dentro de containers Docker, TUDO mesmo.
  4. A interface web é fácil de ser manuseada e de se entender.
  5. A configuração das pipelines é feita inteiramente em arquivos YAML.
  6. Podemos ter pipelines separadas por times.
  7. Sua documentação abrange quase tudo que é necessário para a construção de suas pipelines.
  8. Já possui alguns plugins criados pela comunidade que facilitam a extensão das pipelines.

Tendo um entendimento básico de como o Concourse funciona, subimos duas instâncias EC2 na AWS utilizando o Terraform. Uma instância com o container docker web (contém toda a interface do Concourse e é com ela que os workers se comunicam) e outra com um container docker contendo um worker (responsável por executar as pipelines, se comunica diretamente com o container web).

O fato de tudo utilizar containers Docker nos ajudou bastante e fez com que o processo de subida para a AWS fosse rápido.

Tendo nosso CI em operação, passamos para o próximo passo: as pipelines.

Criando pipelines no Concourse

Se você já é familarizado com o GoCD, talvez conheça o Gomatic. Nele você pode fazer toda a configuração de seu ambiente do GoCD utilizando Python.

No Concourse a nossa única opção era trabalhar com YAML para a criação das pipelines, que por si só não é uma coisa ruim, pois é bem fácil de se manusear até para pessoas que nunca trabalharam com este tipo de arquivo.

A única maneira de interagir e configurar o Concourse é através de sua CLI Fly e isso significa que você terá que ter o binário do Fly em algum lugar, e ele deve ser executado toda vez que houver uma alteração nas pipelines.

A criação de uma pipeline é bem simples:

1. Suba o servidor do Concourse.
2. Crie sua pipeline Yaml. (Exemplos de Pipelines)
3. Utilize o Fly para criar sua pipeline no servidor.
4. Pronto, agora você tem uma pipeline pronta e rodando. Simples, não ?

Bem... agora vamos a alguns probleminhas com o Concourse.

Então... os problemas.

Como nem tudo na vida são flores, começamos a ter problemas quando nossa primeira pipeline evoluiu para mais de uma e quando começamos a ter dependências entre pipelines.

Alguns probleminhas que encontramos:

Um obrigado especial a Melina que compilou essa lista junto comigo.

• A única maneira de se criar pipelines com o concourse é através de sua cli (fly cli).

• A única maneira de interagir e configurar o concourse é também através do fly que se conecta a ele e gera as configurações.

• O Concourse possui o conceito de times que é uma feature maravilhosa, porém você só consegue criar novos times usando sua cli.

• Quando criamos uma nova pipeline usando a cli-fly todo seu conteúdo é exibido em plain-text e isso significa que se alguma credencial for mudada a antiga será exibida.

• Tudo precisa rodar em containeres docker, então quando você precisar que uma pipeline gere uma imagem docker você precisará de trabalhar com docker dentro de docker.

• Seus dashboards começam a ficar muito difíceis de se entender quando temos uma grande quantidade de jobs. Atualmente existe um esforço para melhorá-los, porém ainda em desenvolvimento

• O Concourse se descreve como um modelo de pipelines unificadas, porém a maneira com que ele realmente funciona é por uma serie de jobs independentes.

• Você não pode rodar uma pipeline com uma versão antiga de seu repositório, apenas se você definir a versão do repositório de modo fixo no arquivo pipeline.yml e reconfigurar todas as suas pipelines (https://github.com/concourse/concourse/issues/413).

• No concourse não temos o conceito de upstream e downstream. A única maneira de executar um job é manualmente ou com alguma atualização (check in/commit) em um repositório. É possível definir condições para que um job seja executado como dependência do sucesso de um job anterior, mas esse job não será executado por pelo job anterior.

• Todos os estados dos builds precisam ser passados de job para job na forma de um * resource* que precisa ser guardado em um recurso externo (como o git). O concourse é stateless, o único elemento que mantém o estado no concourse são os recursos que como mencionado, precisam ser versionado e guardados em um data store externo.

• Uma tarefa do Concourse precisa executar dentro de um container docker (a documentação oficial diz que isso não é necessário quando você informa a plataforma, porém quando não utilizamos uma imagem docker um erro é lançado: https://github.com/concourse/concourse/issues/1154)

• Os "workers" do Concourse acabam ficando em um estado chamado "stalled" frequentemente. Tentamos vários tipos de configurações em nossas instâncias da Amazon EC2, porém o problema continuou a ocorrer (pode ser por uma má configuração de nossos arquivos do terraform, mas não conseguimos identificar a causa nem resolver o problema).

Conclusão

Ao final do experimento o que eu posso tirar como conclusão é que por mais promissora que seja a ideia por trás da criação do Concourse, a ferramenta em si não está madura o suficiente para que possa ser utilizada em organizações que tenham várias pipelines complexas e com dependências entre si.

Lembrando que a ferramenta ainda é relativamente nova e possui uma comunidade ativa no github e slack, e por isso pode ser que sua evolução se de de maneira rápida.