‫Bem Olá?
‫Ou devo dizer bem-vindo ao futuro do gerenciamento de software com Docker e ferramentas de contêiner?
‫Este vídeo é especificamente sobre o Docker.
‫Ele teve muitas ferramentas ao longo dos anos, mas este vídeo é sobre as três principais
‫inovações que iniciaram toda a evolução do software Docker em 2013.
‫Isso é basicamente três coisas: a imagem do Docker, o registro do Docker e, em seguida, o contêiner do Docker.
‫A maioria de nós, quando pensamos no Docker, pensamos no contêiner.
‫Mas essas três inovações andam juntas como pão com manteiga, e elas chamam de Add, Docker, build,
‫ship run.
‫Essas são as três etapas para obter um software de ID que não era de contêiner, transformá-lo em uma imagem docker, colocá-lo em um
‫registro, levá-lo para onde você precisar executá-lo e, finalmente, criar um contêiner a partir dele.
‫Na verdade, a Ciencia for the Cloud Native Computing Foundation, sobre a qual muitas ferramentas falarão ao longo de
‫todos os meus vídeos, esses produtos e ferramentas e fluxos de trabalho assumem que, na maioria dos casos, você
‫está usando um fluxo de trabalho de contêiner, um build ship run .
‫Então, vamos decompô-los e exatamente quais são os três.
‫Primeiro, a imagem do contêiner e eu gosto de pensar nela como um empacotador de aplicativos universal e tivemos muitos gerenciadores de
‫pacotes ao longo dos anos.
‫Na verdade, perdi a conta e conheço há algum tempo todos os gerenciadores de pacotes, mas nunca houve nada que
‫eu me lembre que tenha sido multiplataforma de sistema operacional e agnóstico de linguagem de aplicativo, o que significa que ele será executado em todos os
‫lugares e roda em qualquer coisa desde que esteja rodando Linux ou Windows.
‫Agora vamos dar uma olhada rápida em um arquivo Docker, que é a receita ou conjunto de instruções para fazer uma imagem de contêiner,
‫imagem docker e imagem de contêiner são o mesmo termo para a mesma coisa.
‫Na verdade, a especificação de imagem do Docker era tão popular que agora é um padrão conhecido como padrão de imagem
‫OCI.
‫Então você vê um conjunto de instruções e cada arquivo do Docker precisa de um de para começar.
‫Podemos começar a partir da imagem de outra pessoa.
‫Podemos ter muitas imagens de, muitas de.
‫Então, vamos entrar em toda essa complexidade mais tarde.
‫Mas estamos começando com um python aqui e vamos descendo.
‫Na verdade, começamos com elas como camadas.
‫Cada um desses comandos no arquivo do Docker às vezes chamado de estrofe com letras maiúsculas,
‫incluindo o from e depois o run e trabalhando para baixo porque os processa de cima
‫para baixo criará camadas que são movidas pelos servidores como tarballs.
‫E dentro dessas camadas estão arquivos, diretórios e permissões de arquivos e, às vezes, metadados que abordaremos mais
‫tarde.
‫Quando eu começar a construir esta imagem, ela iniciará a primeira linha e irá encontrar a imagem do Python no Docker Hub ou
‫onde quer que eu disse para obter a imagem.
‫E isso inclui apenas Python, seus binários e suas bibliotecas.
‫Ele não contém drivers de host ou o kernel do Linux ou qualquer coisa fora do que o Python precisa para ser executado.
‫Se o Python precisar de SSL aberto, isso será incluído nessa camada da imagem.
‫Em seguida, podemos passar para a próxima linha do arquivo Docker.
‫Esse é um comando PIP para um instalador de dependência do Python e está instalando o frasco.
‫Então, isso iniciará uma nova camada que adiciona o frasco exatamente como você faria com um comando normal de instalação do pip.
‫Na verdade, o que está acontecendo em segundo plano é executar pequenos contêineres rápidos para cada uma dessas camadas,
‫executar os comandos ou fazer o que você precisa fazer dentro dessas camadas e, em
‫seguida, armazená-los como seu próprio local distinto no host Linux que está construindo isso.
‫Então estamos empilhando camadas aqui e então vamos para a próxima linha, o comando de cópia, o trabalho.
‫Há apenas uma mudança de metadados.
‫Ele apenas muda de local no sistema de arquivos, não é grande coisa.
‫O comando copy copia nosso código-fonte do host em que estamos construindo em sua própria camada empilhada sobre
‫as outras.
‫Juntos, eles formam uma imagem usando o comando docker build.
‫Essa é uma daquelas coisas sobre o Docker que se tornou tão fácil de usar porque só precisávamos desse
‫simples comando de compilação do Docker para pegar um monte de coisas complexas acontecendo no arquivo do Docker e transformá-lo em uma
‫única imagem.
‫Esse é apenas o nosso aplicativo e apenas as dependências que ele precisa e nada mais.
‫Essa é a primeira parte da execução do navio de construção sendo construída no Docker.
‫Em seguida, vamos falar sobre o registro.
‫O registro do Docker é para distribuição de aplicativos.
‫Todo sistema de empacotamento de aplicativos tem uma maneira de obter esses pacotes e o registro do Docker não é
‫diferente agora.
‫É conhecido apenas como especificação de distribuição OCI ou especificação de registro OCI.
‫Portanto, é novamente um padrão em todo o setor sobre como mover imagens de contêiner.
‫E está em todo lugar.
‫Cada nuvem tem um.
‫O hub do Docker é o padrão e provavelmente o mais popular.
‫O GitHub tem um Bitbucket GitLab.
‫Todos eles têm seus próprios registros de imagem e você pode executar o seu próprio.
‫Provavelmente, há pelo menos uma dúzia de projetos de software gratuito, de código aberto e pago que permitem
‫armazenar suas imagens do Docker neles.
‫Então, vamos detalhar como isso funciona.
‫Primeiro, temos nossa imagem que acabamos de construir, e essa imagem tem um hash único que identifica todas essas camadas juntas
‫de uma maneira que podemos garantir que, se observarmos o hash em dois sistemas diferentes, podemos ter certeza
‫de que é exatamente os mesmos arquivos, exatamente os mesmos metadados que acabamos de construir.
‫Essas camadas de imagem vão juntas e se distribuem.
‫Podemos usar algo como o Docker Push para pegar essas camadas de imagem e enviá-las para um registro.
‫Você pode usar um dos muitos registros, como mencionei, mas uma vez lá, você pode
‫ir para outra máquina e fazer um Docker pull, que puxará uma cópia idêntica dessa imagem para essa máquina, assim como
‫a construímos. a primeira máquina.
‫E este é um dos princípios centrais do Docker, é que podemos pegar o
‫software que fizemos em uma máquina com todas as suas dependências e executá-lo exatamente da mesma maneira em outro
‫sistema que pode ser distribuições completamente diferentes do Linux ou Windows.
‫Se você estiver no Linux e criar uma imagem do Linux que precisa ser executada no Linux, pois está executando os binários do Linux.
‫Se você o construísse no CentOS e o executasse em um Bonita, seria exatamente o mesmo aplicativo e
‫dependências, independentemente dessa distribuição.
‫Por fim, chegamos ao próprio contêiner do Docker.
‫Uma vez que tenhamos feito todas essas etapas de construção da imagem, colocando-a em um local, podemos
‫acessá-la de nossos servidores e baixá-la em nossos servidores.
‫Podemos executá-lo.
‫Vamos imaginar que temos um servidor rodando Linux.
‫Pode estar executando o Windows, mas neste caso vamos nos concentrar apenas no Linux.
‫Ele terá o Docker sendo executado em segundo plano, conhecido como mecanismo do Docker.
‫E o mecanismo nesta única máquina orquestrará ou gerenciará todas as coisas diferentes que
‫precisam acontecer para baixar imagens, verificar se elas são exatamente o que deveria ser baixado
‫e, finalmente, executá-las.
‫Em seguida, obtemos a imagem que acabamos de baixar com uma pesquisa do Docker e vamos executar um comando.
‫Não é realmente importante que você aprenda os comandos ainda, mas é um comando de execução do Docker.
‫Esta é a parte de execução da execução do navio de construção.
‫E, neste caso, estamos executando esse aplicativo Python em seu próprio contêiner.
‫Esse contêiner é conhecido como namespace.
‫Esse é o recurso do Linux que impede que o aplicativo em execução nesse contêiner veja o restante
‫do sistema operacional.
‫Ele obtém seu próprio sistema de arquivos em branco e incluirá apenas os arquivos que estavam na imagem que acabamos de
‫criar.
‫Ele terá seu próprio endereço IP e seu próprio nic virtual e sua própria lista de processos e basicamente se parecerá com
‫seu próprio sistema lá dentro.
‫Então, se executarmos esse comando de execução do Docker novamente com nosso nome de imagem ou hash de imagem, obteremos um contêiner
‫idêntico sendo executado lado a lado.
‫Agora, esses dois processos estão isolados um do outro.
‫Portanto, o aplicativo Python, um contêiner um, não pode ver o aplicativo Python e o contêiner dois.
‫E se você alterar um arquivo no contêiner para o contêiner um, não verá esse arquivo por padrão.
‫Se adicionarmos um segundo servidor com uma segunda instância do mecanismo do Docker em execução e fizermos a mesma coisa,
‫poderíamos ter uma configuração altamente disponível com nosso aplicativo, executando muitas vezes para redundância ou melhor desempenho ou
‫qualquer que seja o motivo para executar mais do que um deles.
‫Eles serão idênticos do ponto de vista do sistema de arquivos, das permissões e dos metadados.
‫Agora, há muito mais que podemos aprender sobre essas coisas, e é por isso que o curso que tenho é
‫tão longo agora.
‫Mas essas ainda são as três coisas que não mudaram depois do Docker.
‫Primeiro os conceituou.
‫A ideia do build ship run é um dos princípios centrais do container e do leme do Kubernetes.
‫Você nomeia o projeto no ecossistema nativo da nuvem e provavelmente assume que você tem esse tipo típico
‫de fluxo de trabalho para tirar seus aplicativos das mãos do desenvolvedor para os sistemas de teste e, finalmente, para os
‫servidores de produção.
‫São essas mesmas três etapas, então espero que esteja começando a entender um pouco que você entenda por que esses
‫são os três componentes principais.
‫Ainda hoje, muitos, muitos anos depois que tudo isso foi inventado, vamos descobrir o que vem a seguir.