O Docker é muito popular agora, e a tecnologia de contêineres parece ser onipotente, mas isso é realmente um mal -entendido. Não fique fascinado com a bolha do hype. Este artigo joga fora o hype e lista racionalmente os cinco mal -entendidos atuais do Docker da perspectiva dos programadores Java para ajudá -lo a entender melhor as vantagens e os problemas do Docker.
Deixando de lado o hype da mídia e dos fabricantes, como podemos usar o Docker melhor e mais racionalmente?
Docker atraiu muita atenção recentemente e os motivos são óbvios. Como entregar com êxito o código sempre incomodou a todos. A tecnologia tradicional de contêineres é caótica entre muitas necessidades e modelos. O Docker pode criar contêineres de maneira simples e repetida. O uso do Docker permite entrega de código mais rápida e natural do que outros contêineres. Duang, Docker é popular! Existem também alguns mal -entendidos e mal -entendidos. Não confie em outras pessoas para dizer que o Docker é fácil de usar ou não. Pensar em Docker racionalmente e de maneira abrangente por si mesmo o ajudará a entender realmente se você realmente precisa.
Este artigo lista cinco principais interpretações incorretas do Docker de uma perspectiva Java. Mas primeiro introduz algum conhecimento de fundo. Para entender melhor o Docker, consultamos Avishai Ish-Shalom de Fewtes, que tem uma vasta experiência no Docker e também é o organizador da Conferência do DevOps Days. Listamos esses mal -entendidos com ele.
Principal mal -entendido
1. Docker é uma máquina virtual leve
Este é o principal mal -entendido quando você iniciante o Docker. Esse mal -entendido é compreensível, o Docker parece um pouco como uma máquina virtual. Algumas pessoas até comparam a diferença entre o Docker e as máquinas virtuais no site do Docker. No entanto, o Docker não é realmente uma máquina virtual leve, mas um contêiner Linux aprimorado (LXC). Docker e máquinas virtuais são completamente diferentes. Se você usar contêineres do Docker como máquinas virtuais leves, encontrará muitos problemas.
Antes de usar o Docker, você deve entender que existem muitas diferenças essenciais entre os contêineres do Docker e as máquinas virtuais.
Isolamento de recursos: o Docker não pode atingir o nível de isolamento de recursos que uma máquina virtual pode fornecer. Os recursos da máquina virtual são altamente isolados e o Docker precisou compartilhar alguns recursos desde o seu início. Esses recursos não podem ser isolados e protegidos pelo Docker, como Page Cache e Kernel Entropy Pool. (Nota: o pool de entropia do kernel é interessante, coleta e armazena bits aleatórios gerados pelas operações do sistema. A máquina usará esse pool quando precisar ser randomizado, como relacionado a senha.) Se o contêiner do Docker ocupar esses recursos compartilhados, outros processos só podem esperar antes que esses recursos sejam lançados.
Despesas: a maioria das pessoas sabe que a CPU e a RAM de uma máquina virtual podem fornecer desempenho físico semelhante a uma máquina, mas há muita sobrecarga de IO adicional. Como o sistema operacional convidado das máquinas virtuais é abandonado, o pacote do Docker é menor e requer menos sobrecarga de armazenamento do que as máquinas virtuais. Mas isso não significa que o Docker não tenha problemas aéreos. Os contêineres do Docker ainda precisam prestar atenção à sobrecarga de IO, mas não são tão graves quanto as máquinas virtuais.
Uso do kernel: os recipientes do docker e as máquinas virtuais são completamente diferentes no uso do kernel. Cada máquina virtual usa um kernel. Os contêineres do Docker compartilham kernels entre todos os recipientes. Os grãos compartilhados trazem alguns ganhos de eficiência, mas às custas de alta disponibilidade e redundância. Se ocorrer uma falha no kernel em uma máquina virtual, apenas a máquina virtual nesse kernel será afetada. Se o kernel do recipiente do Docker for acertado, todos os contêineres serão afetados.
2. Docker torna as aplicações escaláveis
Como o Docker pode implantar código em vários servidores em um tempo muito curto, naturalmente algumas pessoas pensam que o Docker pode tornar o próprio aplicativo escalável. Infelizmente, isso está errado. O código é a pedra angular do aplicativo e o Docker não reescreve o código. A escalabilidade de um aplicativo ainda depende do programador. O uso do Docker não facilita a escala automaticamente do seu código, apenas facilita a implantação dos servidores.
3. Docker é amplamente utilizado em ambientes de produção
Como o Docker está em pleno andamento, muitas pessoas acreditam que o Docker pode ser usado em larga escala em ambientes de produção. De fato, isso não está certo. Observe que o Docker ainda é uma tecnologia muito nova, imaturo e crescente, o que significa que ainda existem muitos bugs e recursos irritantes a serem aprimorados. É verdade que você está interessado em novas tecnologias, mas é melhor descobrir os cenários de uso corretos e o que precisa ser prestado. Agora, o Docker é fácil de aplicar em ambientes de desenvolvimento. O uso do Docker pode criar facilmente muitos ambientes diferentes (pelo menos, dá às pessoas a sensação de que elas podem criar ambientes diferentes), o que é muito útil para o desenvolvimento.
Nos ambientes de produção, a imaturidade e a imperfeição de Docker também limitam os cenários de uso. Por exemplo, o Docker não suporta diretamente o monitoramento de redes e recursos para várias máquinas, o que torna quase impossível usar em ambientes de produção. Obviamente, existem muitas áreas em potencial, como implantar diretamente o mesmo pacote do ambiente de desenvolvimento para o ambiente de produção. Existem também alguns recursos de tempo de execução do Docker que também são úteis para ambientes de produção. Mas, em geral, no ambiente de produção, atualmente não há mais vantagens do que vantagens. Isso não significa que não possa ser aplicado com sucesso ao ambiente de produção, mas agora não se pode esperar amadurecer e aperfeiçoar de uma só vez.
4. Docker é cruzado
Outro mal -entendido é que o Docker trabalha em qualquer sistema operacional e ambiente. Isso pode vir de uma analogia de contêineres para carregar e descarregar mercadorias, mas a relação entre software e sistemas operacionais não é tão simples e direta quanto a posição do navio.
De fato, o Docker é apenas uma tecnologia no Linux. Além disso, o Docker conta com recursos específicos do kernel e deve ter a versão mais recente do kernel. Com base nas diferenças entre os SOs diferentes, se você não usar os recursos comuns mais baixos entre os sistemas operacionais, encontrará muitos problemas problemáticos. Esses problemas podem ter apenas uma incidência de 1%, mas quando você implanta em vários servidores, 1% também é fatal.
Embora o Docker seja executado apenas no Linux, ele também pode ser usado no OS X ou no Windows. O uso do boot2docker executará uma máquina virtual Linux em uma máquina OS X ou Windows, para que o Docker possa ser executado nesta máquina virtual.
5. Docker aprimora a segurança do aplicativo
Também é um mal -entendido que o Docker possa melhorar a segurança do código e do processo de entrega. Essa também é a diferença entre um contêiner real e um contêiner em um software. O Docker é uma tecnologia de contêiner que adiciona métodos de orquestração. No entanto, os contêineres Linux têm algumas vulnerabilidades de segurança que podem ser atacadas. O Docker não adiciona camadas de segurança ou patches a essas vulnerabilidades. Não é uma camisa da calça que pode proteger os aplicativos.
De uma perspectiva java
Alguns desenvolvedores de Java começaram a usar o Docker. Alguns dos recursos do Docker facilitam a criação de contextos escaláveis. Ao contrário do Uber-Jar, o Docker pode ajudá-lo a embalar todas as suas dependências (incluindo JVM) em uma imagem pronta para o lançamento. Esta também é a coisa mais fascinante sobre o Docker para os desenvolvedores. No entanto, isso também trará alguns perigos ocultos. De um modo geral, os programadores precisam monitorá -lo de diferentes maneiras e código interativamente, depurar, conectá -lo, ajustá -lo ... se você usar o Docker, eles exigirão trabalho adicional.
Por exemplo, queremos usar o JConsole, que depende das funções JMX, porque o JMX precisa de redes para usar o RMI. Não é muito direto se você usar o Docker e precisar de algumas habilidades para abrir a porta necessária. Inicialmente, descobrimos que o problema era que, quando queríamos criar um aplicativo do Docker para Takipi, tivemos que executar um programa de fundo fora da JVM no contêiner. Solução detalhada no Github.
Outro problema sério é que o ajuste de desempenho dos contêineres do Docker é bastante difícil. Ao usar contêineres, você não sabe quanta memória cada contêiner alocará. Se você tiver 20 contêineres, a memória será alocada a eles de maneiras incertas. Se você planeja ajustar a pilha com o parâmetro -xmx, é difícil porque o processamento da JVM no contêiner do docker depende da capacidade de obter automaticamente a memória alocada ao contêiner. O ajuste do desempenho é quase impossível se você não souber quanta memória é alocada.
para concluir
O Docker é uma tecnologia muito interessante e possui alguns cenários de uso reais e eficazes. Como uma tecnologia emergente, também leva muito tempo para resolver recursos ausentes e bugs conhecidos. No entanto, há de fato muito hype neste campo agora. Mas lembre -se, o hype não é um sucesso ~
Obrigado pela leitura, espero que isso possa ajudá -lo. Obrigado pelo seu apoio a este site!