Cria¸c˜ ao do docker-compose.yml

A cria¸c˜ao de um ficheiro de lan¸camento da aplica¸c˜ao para pre-live vai envolver a execu¸c˜ao de quatro containers. O primeiro container a ser lan¸cado ser´a o da base de dados porque sem ela a aplica¸c˜ao simplesmente n˜ao funciona. De seguida s˜ao executados dois containers com duas aplica¸c˜oes da Web API do servi¸co de gest˜ao de tarefas, em duas portas diferentes e com HostingEnvironments diferentes. Por ´

ultimo lugar, ´e executado o servi¸co de load balancing da aplica¸c˜ao.

Servi¸co de base de dados

O servi¸co de base de dados utilizado – MS SQL Server – ´e o primeiro a ser executado e todos os restantes servi¸cos dependem do seu funcionamento. Conv´em ter em conta que os dois servi¸cos da Web API devem aguardar que a base de dados esteja lan¸cada (4.9) e devidamente configurada para, s´o depois, poderem arrancar. Para ultrapassar este problema ´e necess´ario garantir que o servi¸co da Web API s´o ´

Figura 4.9 – Servi¸co de base de dados da aplica¸c˜ao

Para este caso a solu¸c˜ao passou pela implementa¸c˜ao de um ciclo de tentativas de conex˜ao ao servi¸co de base de dados com recurso a um try-catch. Como pode ser visto na figura 4.10, no bloco try vai ser utilizado o contexto da base de dados que foi configurado para serem feitas as migra¸c˜oes. Enquanto que na cl´ausula catch ´e feito um ciclo de 10 tentativas de conex˜ao `a base de dados.

Servi¸co de Web API

Os dois servi¸cos da Web API dependem do servi¸co de BD para poderem fun- cionar. O servi¸co time-management-api1 apresenta a vari´avel de ambiente com a configura¸c˜ao de Release por defeito. J´a o servi¸co time-management-api2 apresenta uma vari´avel de ambiente diferente ao utilizador apesar de ter a mesma configura¸c˜ao de Release do seu par. Como se pode ver pela figura 4.11, nas vari´aveis de ambi- ente time-management-api2, o valor de HostingEnvironment daquela instˆancia ´

e definido como “Test” atrav´es da utiliza¸c˜ao da vari´avel de ambiente ASPNET- CORE ENVIRONMENT=Test. Assim sendo, quando for utilizado o load ba- lancer para distribuir os pedidos pelas duas Web APIs sabe-se, atrav´es do sufixo apresentado no t´ıtulo, qual a instˆancia da API que est´a a ser apresentada no browser.

Figura 4.11 – Servi¸co de apresenta¸c˜ao da Web API

Servi¸co de Load Balancing

Da mesma forma que os servi¸cos da Web API dependem do servi¸co de base de dados para poderem ser inicializados, os servi¸co de load balancing vai esperar que as duas APIs estejam lan¸cadas para poder ser executado. Pela figura 4.12 pode verificar-se que o nginx ´e o ´ultimo servi¸co a ser executado.

Figura 4.12 – Servi¸co de load balancing

Ap´os a fase de development, os passos para a publica¸c˜ao de um servi¸co repetem- se sistematicamente. A seguir `a cria¸c˜ao das imagens que v˜ao compor o servi¸co nas fases de pre-live e production, ´e sempre produzido um ficheiro de composi¸c˜ao (docker-compose.yml) que vai orquestrar a publica¸c˜ao da aplica¸c˜ao, servi¸co a servi¸co, pela sequˆencia cronol´ogica de instru¸c˜oes de publica¸c˜ao que lhe s˜ao transmi- tidas.

4.1.4

Considera¸c˜oes

Este tipo de metodologia de publica¸c˜ao pode ser utilizado localmente ou online, com uma condi¸c˜ao. Na m´aquina onde o servi¸co ´e publicado, ter´a de estar instalado o Docker.

Caso o servi¸co esteja publicado em rede local, como por exemplo, na m´aquina de staging disponibilizada pela empresa, os custos de opera¸c˜ao passam a ser ´unica e exclusivamente a energia consumida pela m´aquina, contrariamente ao que acon- tece quando um servi¸co ´e publicado online para ser testado. Uma das principais vantagens ´e a facilidade com que se consegue replicar toda a infra-estrutura, o que facilita n˜ao s´o o desenvolvimento em si, mas tamb´em a pipeline de teste, porque desta forma ´e poss´ıvel criar e destruir os ambientes facilmente.

Um dos contratempos da utiliza¸c˜ao do Docker (vers˜ao do Windows) ´e a perda de dados em situa¸c˜oes como, por exemplo, quando uma m´aquina ´e reiniciada sem existir persistˆencia de dados. Estes dados nunca mais ser˜ao recuperados, uma vez que por defini¸c˜ao os containers s˜ao vol´ateis. Assim sendo, para contornar este

problema ´e necess´ario utilizar containers para guardar os dados das aplica¸c˜oes que est˜ao a ser utilizadas, e utilizar os seus volumes como reposit´orios de dados. Desta forma os dados ficar˜ao sempre persistidos na mem´oria dos outros containers, mesmo que o servi¸co do Docker falhe inesperadamente.

Os pr´oximos passos ser˜ao a implementa¸c˜ao de uma pipeline de integra¸c˜ao e entrega cont´ınua para um servi¸co da plataforma Yugoup. Para tal, ser´a criada uma branch paralela `a Master – chamada cicd – que permitir´a trabalhar em conformi- dade com os objetivos estabelecidos pela equipa de orienta¸c˜ao sem interferir com os desenvolvimentos da equipa da empresa. O servi¸co mais importante da plataforma, o Tenant, foi o escolhido para percorrer todas as fases de integra¸c˜ao cont´ınua.