O festival RIT 2018 em Skolkovo foi grande e muito diversificado. Desenvolvimento móvel, back-end, front-end, DevOps, gerenciamento de projetos e até psicologia são tópicos para todos os gostos e em uma agenda cheia, de manhã a noite. Os temas são divididos em faixas separadas, as faixas são ligadas aos corredores. Se apenas relatórios especializados forem interessantes, você poderá se instalar na sala certa. A sala de palestras, no entanto, foi usada conforme necessário pelos palestrantes de vários tópicos.
De modo geral, fui esclarecido com o conhecimento do DevOps e, depois de compartilhar minhas impressões da conferência com meus colegas, fiz uma pequena lista de relatórios que me lembrava. Vários meses se passaram e eu ainda me lembro bem do que eles estavam falando.
Então, três relatórios técnicos que eu lembrei no RIT 2018.
Monitoramento e Kubernetes
As ferramentas de monitoramento usadas agora não suportam muito bem aplicativos de arquitetura de microsserviço. Quanto mais dinâmica no sistema, mais difícil é configurar o monitoramento para ele. O monitoramento conveniente de sistemas de cluster, como o Kubernetes, que leva a dinâmica ao extremismo, geralmente é uma tarefa não trivial. Porque Dmitry Stolyarov, diretor técnico da Flant, fala sobre os motivos dessa complexidade e seu impacto na principal missão de monitoramento.
Os sistemas de monitoramento tradicionais dependem do trabalho com servidores estáticos, que são raramente adicionados e removidos da infraestrutura de aplicativos. No Kubernetes, a criação e a exclusão de ambientes de lareira e aplicativos de serviço acontecem a cada segundo; portanto, os procedimentos de descoberta automática existentes simplesmente não conseguem lidar com esse volume.
O número de ambientes em si também está na casa das dezenas e centenas. Por conseguinte, a quantidade de telemetria transmitida aumenta na mesma quantidade. E ela ainda precisa ser armazenada em algum lugar.
Um problema separado é a colisão dos mundos físico e virtual: o consumo de recursos por aplicativos no Kubernetes é bastante efêmero e se reflete em termos de restrições aos lares. Mas o consumo de recursos de pod já tem um efeito físico específico nas capacidades disponíveis do servidor. Ao analisar gráficos, você sempre deve considerar de que ponto de vista analisa os recursos. Na prática, poucas pessoas estão interessadas em pods individuais. De interesse é o consumo de recursos pelo aplicativo como um todo, e isso já exige um agrupamento flexível de pods de telemetria de acordo com alguns critérios definidos pelos usuários.
E você precisa aumentar o esquema resultante várias vezes para os amplos ambientes de desenvolvimento / preparação / produção!
O relatório é recomendado para quem precisa oferecer suporte ao cluster kubernetes.
Link para a apresentação.
Devops de Desenvolvimento de Caixas
Foi extremamente interessante para nós ouvir o relatório de Maxim Lapshin, no qual ele compartilhou a rara experiência de usar práticas de dev no desenvolvimento de produtos em caixas. Um produto in a box é um software tradicional que instala e executa nos recursos do usuário.
Erlyvideo está desenvolvendo um servidor de streaming de vídeo, somos um servidor de configuração de serviços de Internet. Nossos problemas são de muitas maneiras semelhantes aos que causaram a transformação de DevOps do ErOlvideo.
Maxim inicia o relatório com uma resposta para a pergunta mais importante: "Para que serve tudo isso?" Todos os mesmos fatores que impulsionam a introdução da cultura DevOps no desenvolvimento de serviços também estão presentes em setores onde está ocorrendo um desenvolvimento mais tradicional. E a influência desses fatores nos produtos embalados provavelmente será mais dramática do que quando se trabalha em um serviço. Por exemplo, quanto menos versões, maior o volume de alterações que serão implantadas. Se você estiver lançando um novo serviço, pode ter certeza ou apenas se convencer de que é seguro. Mas se você liberar uma distribuição de produtos com um grande número de alterações, não será suficiente para você se convencer da segurança da atualização, também precisará convencer seus usuários da segurança. Pequenos, mas frequentes, pedaços de mudança vêm em socorro aqui. E este é apenas um dos problemas.
O relatório detalha essa e muitas outras razões para usar a entrega contínua, traçar paralelos e enfatizar as diferenças do trabalho geralmente mais simples no modo CI / CD com serviços.
Como isso é possível? No relatório, Maxim descreve o conjunto de práticas usadas no Erlyvideo para tornar real a entrega contínua do fluxo de mudanças. Muitas abordagens serão úteis como estão, algo exigirá adaptação às realidades do nosso trabalho. Mas, em qualquer caso, essa maravilhosa história de sucesso pode inspirar a repensar seus problemas e encontrar soluções em uma variedade de práticas de DevOps.
O relatório será muito interessante para todos que trabalham na distribuição de produtos.
Link para a apresentação.
Bases de rede Kubernetes
O onipresente guia de início rápido, curso intensivo e tutoriais “Como começar com o kubernetes” tornam relativamente fácil entrar neste carro, implantar um cluster e implantar o aplicativo. Dada a incrível popularidade deste tópico, muitos o fazem. Mas não esqueça que, em essência, o Kubernetes é um sistema bastante complexo, cuja manutenção requer conhecimento específico. No Ingram Micro Cloud, esse conhecimento era necessário quando o próximo aplicativo ficou indisponível de repente na rede. A partir da investigação desse incidente, começou a fascinante jornada de Alexander Khayorov através do subsistema de rede.
O relatório apresenta os elementos cada vez mais complexos da pilha de rede Kubernetes, explicando como o roteamento grande e complexo é composto de blocos elementares. Isso se mostra especialmente interessante quando Alexander fala sobre por que isso é feito, e não de outra forma, modelando outras opções de implementação hipotéticas.
Este é realmente o alfabeto Kubernetes que a maioria dos usuários encontrará. Eu mesmo fiz as perguntas "por que o nodePort?" e "por que não vejo o IP do meu serviço na interface?"
Interessante e informativo.
Link para a apresentação.