<aside> 🐋 Este projeto é pra você instalar, configurar e fazer rodar o seu primeiro servidor web, com um detalhe: cada pedaço dos programas que você precisa para fazer o servidor funcionar devem estar em um contêiner diferente! Sua missão é fazer todas as partes conversarem entre si para entregar o resultado final, seu próprio site: www.seunominhoaqui.42.fr !
</aside>
palavras-chave: …
👏 Nunca. 👏 Caia. 👏 No. 👏 Papinho. 👏 De que: “Ahhh projeto X é fácil!!!!!”. As únicas pessoas que falam isso são as pessoas que 1. já entregaram o projeto, e 2. já tinham uma montanha de repertório sobre o subject do projeto quando pegaram pra fazer.
Eu achava que eu me encaixaria mais ou menos na segunda categoria de pessoas, porque afinal, eu já sei o que é o Docker e eu já trabalhei com contêineres. A própria página de introdução do PDF dá a entender que você só vai precisar subir uns contêineres, e fim. “Fácil”, eu pensei, “só pegar umas imagens prontas, e já era”.
Bom, estou aqui pra te dizer que se você ainda não sabe o que é Docker (e uma imagem/um contêiner), isso é algo que você vai aprender fazendo esse projeto 😄 Mas para além disso, existe muita, mas MUITA coisa mais envolvida na entrega desse projeto, então se assim como eu você chega nesse projeto já sabendo o que é o Docker, as imagens e os contêineres, a notícia que eu tenho pra te dar é: segura que lá vem tranco.
O objetivo desse projeto é colocar o site www.seulogindaintra.42.fr de pé. Mais ou menos, porque o que você não vai fazer nesse projeto é de fato colocar o seu site online pra ser acessado por qualquer computador conectado à internet na face da terra. Você pára um passo antes disso. Mas tirando essa parte — que se chama “hospedar um site”, “colocar um site em produção” ou “implantar um site” —, o objetivo desse projeto é criar toda a infraestrutura de componentes e programas necessárias para que um site vá (eventualmente) ao ar na internet! ****
Existem diversas formas de fazer isso, incluindo diversas tecnologias (linguagens de programação, frameworks, programas) possíveis para fazer isso acontecer. Esse projeto te pede (de maneira implícita, óbvio 🤦) para utilizar um conjunto muito específico de tecnologias para alcançar o objetivo: a famigerada LEMP stack! — o termo “stack” aqui fazendo alusão ao fato de que é um conjunto de tecnologias que muito frequentemente são utilizadas juntas. A ideia é que, supondo que você vai comprar um computador, instalar ele na sua casinha, e a única e exclusiva função desse computador vai ser hospedar os arquivos do seu site, tendo para isso que ficar ligado 24h na energia, usando as tecnologias propostas pela LEMP stack, você vai precisar que: o seu computador rode com um sistema operacional [L]inux; dentro do seu computador você tenha instalado um programa chamado Nginx (se pronuncia [E]ngine-X) que vai ser responsável por receber todas as requisições da face do planeta, e respondê-las (tipo um porta-voz, ou um secretário); o seu site vai ter usuáries que vão guardar coisas como senhas, comentários, amizades, fotos, likes, produtos favoritos, etc., no seu site, e portanto para isso você vai precisar de um banco de dados, especificamente o banco de dados relacional open-source chamado [M]ariaDB; e por último e não menos importante, a carinha do seu site, as cores, o design, as diferentes telas pelas quais es usuáries poderão navegar serão geradas dinamicamente por um framework de PHP muitíssimo conhecido, utilizado, amado por uns e odiado por outros, chamado Word[P]ress! (Deu pra ver o que eu fiz pra explicar o acrônimo LEMP? socorro)
Cansou de ler essa introdução? Eu cansei de escrever. Mas ainda não acabou! Prepare-se para a puxada de tapete que vem aí…
“Mas onde entra o Docker nisso tudo?”, você deve estar se perguntando. Bem, em seus estudos você vai entender por quê é uma ideia meio ruim hospedar um site em um único computador na face do planeta terra, no aconchego da sua casinha. E se a energia cair? E se o computador pifar? E se isso acontecer bem quando o seu site popularizou e tem uma galera querendo acessar? É sempre bom ter uma “cópia” das suas coisas guardadas em algum lugar. No Born, a gente aprendeu a criar cópias de máquinas virtuais, lembra? O Docker é uma alternativa mais leve e mais versátil a máquinas virtuais, como você vai vir a aprender. Se você coloca todos os arquivos e programas necessários pra rodar o seu site dentro de um contêiner, fica mais fácil carregar ele de um lado pro outro, ou de criar réplicas em caso de muita gente querendo acessar de uma vez só, ou redundâncias do seu site, para casos de incidentes (como a luz acabar, o cachorro roer os fios de energia, por aí vai).
“Mas onde está a puxada de tapete que você falou? Até agora parece suave…” Veja bem. Não basta a dificuldade de aprender sobre cada pedacinho da LEMP stack para criar o servidor do seu site. Não basta o desafio de aprender sobre contêineres o suficiente pra conseguir criar um único contêiner que contenha tudo o que você precisa pra carregar seu site bonito, cheiroso e penteado de um lado pro outro. Isso por si só já vai te dar um bom trabalho, mas até que os tutoriais da internet vão te ajudar bastante com isso. Agora, o que o pdf vai te pedir, é simplesmente para explodir 🧨💥 toda a infraestrutura que você criou em pedacinhos menores - em vários contêineres! Que antes se comunicavam entre si internamente no seu computador na sua sala de estar, e agora é como se cada pedaço do seu site estivesse em um computador em um cômodo diferente da sua casa, e além de fazer cada parte funcionar sozinha, sua missão é conectar todas as partes pra funcionarem juntas como um todo.
Mas é óbvio que aqui é a 42, e se fosse pra fazer os projetos usando tutoriais prontos da internet, não ia ser a 42, certo? Um detalhe muito importante é que nesse projeto você tem que escrever as suas Dockerfiles na unha — é proibido usar imagens prontas do Docker Hub neste projeto! Bem jeitinho 42 de ser. Isso vai te exigir que desenvolva uma noção mais íntima e concreta do que de fato compõe uma imagem Docker, e de como é o processo de criar (build) e depois subir (run/up) um contêiner.
Minha grande crítica a esse projeto dentro da 42 São Paulo é a seguinte: desenvolvimento web é um dos pilares da nossa profissão (se não for o maior de todos!). Hoje em dia negócios inteiros, e muito lucrativos, se baseiam em sites na internet. Por esse lado, a relevância desse projeto é inquestionável. E inclusive, o seu escopo é muito relevante pois é uma prática comum no mercado de hoje em dia ter vários containers rodando serviços conversando entre si. No entanto, o tanto de conhecimento que esse projeto nos exige simplesmente não é congruente com tudo o que vimos nos projetos pra trás durante a trilha de fundamentos! E isso é MUITO frustrante. Esse projeto é péssimo para servir de introdução ao mundo do desenvolvimento web. É como se você tivesse acabado de entregar a sua ft_printf, e te pedissem em seguida pra escrever um Cub3D ou um MiniRT. (Ahem. qualquer semelhança com o currículo da 42 no passado não é mera coincidência). É um desafio muito grande pra quem tá chegando agora no rolê! Teoricamente você chegou até aqui sem nunca nem ter escrito um “Hello world” em HTML — pelo menos não pela via da 42 —, e do nada você tem que subir um servidor de um site com conteúdo dinâmico, intermediado por um servidor de proxy reverso, conectado com um banco de dados, não apenas isso mas colocar cada peça em um contêiner, configurar uma rede pra os contêineres conversarem entre si, e um milhão de coisinhas mais que você precisa aprender no meio do caminho. É injusto. É revoltante. Mas é o que temos pra hoje.
Esse projeto te exigirá entender mais do mundo de desenvolvimento web: o que é a internet, afinal? O que é um site? O que era um site em 1990, e o que é um site hoje na terceira década do século 21? Como as coisas simples vão engrossando e se tornando mais complexas, e quais são as estratégias e ferramentas que a comunidade de pessoas desenvolvedoras criou ao longo do tempo para endereçar os desafios do crescimento, da grande escala, de cada vez mais pessoas no mundo ganhando acesso à internet? Ter ideia desse panorama é muito importante, principalmente porque neste projeto você vai utilizar ferramentas gigantes e prestigiadas no mundo de web dev, pra resolver um problema pequenininho 🤏 que é colocar um site de pé. Então, é muito fácil se perder na miríade de tutoriais, guias, vídeos e artigos que existem sobre cada uma das ferramentas gigantes que você precisará utilizar nesse projeto, e perder de vista o que de fato você está fazendo, porque está fazendo o que está fazendo, e o que é o mínimo necessário pra alcançar seu objetivo. Espero que este acelera te ajude de alguma forma nessa missão 💜
Você está seguindo sua vida de boas, quando do nada te falam que você precisa “instalar um cliente”, ou que “tá dando problema no servidor”. Você não faz a menor ideia do que está acontecendo, mas a naturalidade com que te falam essas coisas te faz se questionar se não tem alguma coisa de errado com você por não fazer a mínima ideia do que diabos “cliente” e “servidor” significam. Você já passou por uma situação parecida? Eu detesto esse linguajar “tecniquês” de palavras que são vagas, e são salpicadas por tudo quanto é canto sem nenhum compromisso com inteligibilidade, de maneira que quem tem o contexto entende o que está sendo falado, e quem não o tem: 🤷 turn yourself around. Se vira.
Estas duas palavras se referem a computadores que estão conversando entre si. Surgem pela necessidade de nomear o papel de cada um desses computadores durante essa interação. De novo, volto no fato de que todos os projetos que foram codados até aqui no currículo são projetos que acontecem dentro de um único computador, geralmente um único processo rodando no computador, sem a necessidade de se comunicar com outros processos, muito menos com outros computadores. (O minitalk é mais ou menos uma excessão porque dois processos conversam entre si, mas de toda forma, dois processos dentro de um único computador). Então, essas palavras são novas, e não só isso: servem para nomear coisas novas que você nunca antes viu trilhando o currículo da 42 até agora. Elas servem para nomear cada uma das partes durante uma interação de comunicação entre computadores.
“Cliente” se refere ao computador que inicia a conexão com o outro, com o objetivo de obter acesso a (em outras palavras, pedir) algo que está guardado lá (um site, um arquivo). “Servidor” se refere ao computador que recebe o pedido de conexão, e que muitas vezes possui arquivos, páginas da internet, ou algum tipo de recurso que o cliente está solicitando, e que, uma vez que a conexão tenha sido estabelecida de maneira segura, o servidor irá transmitir (em outras palavras, irá servir) para o cliente.