Na zona Instˆancia do Swish est´a representa a aplica¸c˜ao Web e base de dados respetiva, desenvolvidas no cap´ıtulo anterior. Cada organiza¸c˜ao inscrita na plataforma ter´a uma r´eplica `a sua medida desta zona, seguindo os fundamentos do modelo multi-instance, referido anteriormente.
Foi criada uma aplica¸c˜ao Web de gest˜ao de instˆancias com o ASP.NET Core para oferecer aos administradores da plataforma uma interface para a cria¸c˜ao, edi¸c˜ao, bloqueio e elimina¸c˜ao de instˆancias e para a gest˜ao dos utilizadores e das instˆancias `
as quais estes possuem acesso. As instˆancias ir˜ao comunicar com esta aplica¸c˜ao para conseguirem alguns dos dados dinˆamicos que necessitam para executarem os pedidos dos utilizadores.
A autentica¸c˜ao dos utilizadores ´e feita num sistema de autentica¸c˜ao centralizada, que faz uso do Identity Server4 5, um middleware feito em .NET que usa o Oauth
2 e o OpenID Connect para permitir a autentica¸c˜ao de utilizadores e aplica¸c˜oes.
5.3
Docker
O Docker ´e uma tecnologia que facilita o processo de cria¸c˜ao de um artefacto distribu´ıvel de uma aplica¸c˜ao. As suas vantagens estendem-se `as tarefas de distribui¸c˜ao, com a simplifica¸c˜ao do processo de distribui¸c˜ao de software para diferentes ambientes, o que vai de encontro ao princ´ıpios do DevOps, mencionado no subcap´ıtulo 4.2.
Os conceitos containers Docker e m´aquinas virtuais s˜ao muitas vezes confundidos e, apesar de serem ambos tipos de virtualiza¸c˜ao, o conhecimento das suas diferen¸cas ´
e fulcral na escolha da tecnologias que mais se adequa. A Figura 5.3 apresenta as diferen¸cas de implementa¸c˜ao do Swish usando o Docker e uma arquitetura com m´aquinas virtuais.
As m´aquinas virtuais permitem que os utilizadores emulem sistemas operativos dentro de um sistema operativo j´a existente. Cada instˆancia de uma m´aquina virtual cont´em uma c´opia do sistema operativo e todas as dependˆencias necess´arias para
72 CAP´ITULO 5. SWISH COMO UM SERVIC¸ O
Figura 5.3 – Diferen¸cas de implementa¸c˜ao do Swish usando o Docker e m´aquinas virtuais.
que seja executada, sendo que pode demorar v´arios minutos a arrancar.
Os containers s˜ao executados no topo da camada do sistema operativo o podem partilhar o mesmo n´ucleo, como se pode observar na Figura 5.3. Cada container ´e executado como um sistema isolado (Bui,2015) e pode ou n˜ao ser ligado a outros containers. Tipicamente, um container ocupa pouco espa¸co, especialmente quando comparado com uma m´aquina virtual e demora poucos segundos a iniciar.
5.3.1
Imagens e reposit´orios Docker
Uma imagem Docker ´e um ficheiro read-only, composto por v´arias camadas, que quando ´e instanciado d´a origem a um Docker container, `a semelhan¸ca do que acontece no paradigma de programa¸c˜ao orientada a objetos, em que a instancia¸c˜ao de uma classe d´a origem a um objeto. No caso da recria¸c˜ao ou atualiza¸c˜ao de uma imagem, apenas as camadas afetadas s˜ao atualizadas.
5.3. DOCKER 73
ficheiro chamado Dockerfile, que ´e executado pelo Docker Engine sempre que ´e solicitada a compila¸c˜ao de uma imagem. Como o desenvolvimento deste projeto seguiu a metodologia DevOps, o processo de compila¸c˜ao das imagens referentes `as aplica¸c˜oes desenvolvidas ´e executado sempre que ocorrem altera¸c˜oes no c´odigo, com recurso ao GitLab CI/CD, supramencionado no subcap´ıtulo 4.2.
A fun¸c˜ao dos reposit´orios Docker, p´ublicos ou privados, ´e o armazenamento e distribui¸c˜ao de imagens. Ap´os o processo de compila¸c˜ao das imagens no GitLab CI/CD, estas s˜ao enviadas para o reposit´orio privado do GitLab, onde ficam dispon´ıveis para uso por parte de utilizadores autorizados.
O Docker possuiu um reposit´orio p´ublico, o Docker Hub, que contem algumas das imagens externas usadas no projeto como as imagens do Portainer, Traefik e MySQL.
5.3.2
Orquestra¸c˜ao de containers com o Docker Compose
O Docker Compose ´e uma ferramenta para definir e executar aplica¸c˜oes compostas por m´ultiplos containers no Docker. A defini¸c˜ao das imagens a serem usadas e configura¸c˜oes dos containers ´e feita atrav´es de um ficheiro YML. Em seguida ´e exposto o ficheiro YAML usado para configurar uma instˆancia do Swish.
1 v e r s i o n: ’2 ’ 2 3 s e r v i c e s: 4 db: 5 image: mysql:8 . 0 . 0 6 command: −−m a x a l l o w e d p a c k e t =32505856 7 e n v i r o n m e n t:
8 MYSQL ROOT PASSWORD: $ {MYSQL DATABASE PASSWORD} 9 MYSQL DATABASE: SportDBDev
10 volumes: 11 - / v a r / l i b / mysql 12 r e s t a r t: a l w a y s 13 n e t w o r k s: 14 - i n t e r n a l 15 l a b e l s:
74 CAP´ITULO 5. SWISH COMO UM SERVIC¸ O
16 - t r a e f i k . e n a b l e=f a l s e 17 s w i s h:
18 image: s w i s h:l a t e s t 19 e n v i r o n m e n t:
20 - AuthUrl=$ {AUTH URL}
21 - C l i e n t I D=$ {CLIENT ID} 22 r e s t a r t: a l w a y s 23 l a b e l s: 24 - t r a e f i k . backend=s w i s h 25 - t r a e f i k . f r o n t e n d . r u l e=Host:$ {CLIENT ID } . l o c a l h o s t 26 - t r a e f i k . d o c k e r . network=web 27 - t r a e f i k . p o r t =80 28 n e t w o r k s: 29 - web 30 - i n t e r n a l 31 d e p e n d s o n: 32 - db 33 n e t w o r k s: 34 web: 35 e x t e r n a l: 36 name: web
Neste YML s˜ao definidos dois servi¸cos, o db, a base de dados que ir´a guardar os dados relativos `a instˆancia e o Swish, a aplica¸c˜ao Web que permite a visualiza¸c˜ao dos jogos e vari´aveis.
No parˆametro image ´e especificada a imagem Docker a ser usada pelo servi¸co. O Docker ir´a, primeiramente, procurar a imagem localmente e, caso n˜ao exista, ir´a procur´a-la no Docker Hub. Podem ainda ser escolhidas imagens presentes em reposit´orios privados. No command podem ser definidas op¸c˜oes relacionadas com as imagens usadas. Neste caso espec´ıfico, o tamanho m´aximo dos pacotes a serem recebidos pelo MySQL foi aumentado para permitir a importa¸c˜ao mais r´apida, com batchs maiores, dos dados espa¸cotemporais.
O environment permite a defini¸c˜ao de vari´aveis de ambiente que podem ser acedidas pelas aplica¸c˜oes. Esta op¸c˜ao foi usada para a defini¸c˜ao do nome da base de dados e da palavra-chave, no caso do MySQL e para a defini¸c˜ao do endere¸co de autentica¸c˜ao e do identificador do cliente.
5.3. DOCKER 75
Os volumes s˜ao usados para persistir os dados gerados por um container e s˜ao guardados num diret´orio ´unico dentro do Docker host. A necessidade do uso de volumes prende-se com o facto de quando um container Docker ´e destru´ıdo, o mesmo acontece com o seu sistema de ficheiros, pelo que os dados s˜ao perdidos.
O restart ´e uma pol´ıtica que define o comportamento do container quando este ´e fechado ou quando o Docker reinicia. No caso espec´ıfico do Swish, a pol´ıtica foi definida como always, para que recomece sempre que seja parado de forma autom´atica.
As labels permitem a adi¸c˜ao de metadados `as imagens e foram usadas para configurar o Traefik. Ser˜ao explicadas no pr´oximo subcap´ıtulo. A cria¸c˜ao de redes no Docker tem como objetivo a comunica¸c˜ao entre containers. Foi criada a rede internal no parˆametro networks, que possibilita o acesso do Swish `a base de dados. Por fim, o parˆametro depends on proporciona a cria¸c˜ao de dependˆencias entre servi¸cos, com o Swish a depender da base de dados, que ser´a inicializada primeiro.
5.3.3
Traefik
O Treafik ´e um proxy reverso e balanceador de carga usada na distribui¸c˜ao de microservi¸cos. O acesso por parte dos utilizadores aos microservi¸cos atrav´es da Internet exige um proxy reverso, respons´avel pelo encaminhar os endere¸cos recebidos para os servi¸cos respetivos. Num proxy reverso, este trabalho ´e feito manualmente, exigindo a configura¸c˜ao de cada rota por parte dos administradores do sistema. Um SaaS usando uma arquitetura multi-instance ´e um sistema dinˆamico, que permite a adi¸c˜ao e elimina¸c˜ao de instˆancias, pelo que a tarefa de atualiza¸c˜ao das rotas pode tornar-se num esfor¸co cuntat´orio.
Ap´os a configura¸c˜ao do Traefik atrav´es de um ficheiro TOML, o proxy reverso vai receber os pedidos HTTP e encaminhar os utilizadores para os containers Docker respetivos. No processo de cria¸c˜ao de instˆancias, ´e escolhido um subdom´ınio ´unico, que permitir´a o acesso `a instˆancia. O nome do subdom´ınio ´e enviado para o ficheiro
76 CAP´ITULO 5. SWISH COMO UM SERVIC¸ O
YML, referido anteriormente e o Treafik toma conhecimento de uma nova instˆancia, pronta para ser usada.
1 s e r v i c e s: 2 db: 3 l a b e l s: 4 - t r a e f i k . e n a b l e=f a l s e 5 s w i s h: 6 l a b e l s: 7 - t r a e f i k . f r o n t e n d . r u l e=Host:$ {CLIENT ID } . l o c a l h o s t 8 - t r a e f i k . d o c k e r . network=web 9 - t r a e f i k . p r o t o c o l=h t t p s
O traefik.enable ´e colocado como falso para a base de dados, bloqueando a exposi¸c˜ao desta ao exterior. A label traefik.frontend.rule define o endere¸co que d´a acesso ao container, com a vari´avel de ambiente CLIENT ID, que cont´em o subdom´ınio, a ser enviada pela aplica¸c˜ao de gest˜ao de instˆancias durante o processo de cria¸c˜ao. No parˆametro traefik.docker.network, a rede web do Docker ´e definida como a rede externa respons´avel por ligar todos os containers necess´arios ao Treafik. O HTTPS consiste na implementa¸c˜ao do protocolo HTTP com uma camada adicional baseada no protocolo SSL/TLS. Nesta camada extra ocorre a encript¸c˜ao dos dados e a verifica¸c˜ao da autentica¸c˜ao do servidor e do cliente, com recurso a certificados digitais (Callegati et al.,2009). O Traefik permite, atrav´es do ficheiro de configura¸c˜ao, o reencaminhamento dos pedidos HTTP para HTTPS e a cria¸c˜ao de autom´atica de certificados com Let’s Encrypt6, uma autoridade de certifica¸c˜ao que
tem como objetivo transformar as conex˜oes encriptadas no padr˜ao da Web. Desta forma, ´e poss´ıvel a encripta¸c˜ao dos pedidos feitos a qualquer um dos containers presentes na infraestrutura do sistema.