Docker costumava ser uma coisa legal e jovem por si só. E então, de alguma maneira, o estivador deixou de ser interessante: ele simplesmente é, está em todos e em tudo. Tem todos os microsserviços, Kubernetes, devops - qualquer coisa. No entanto, as pessoas arrastam recipientes para a boca de qualquer lugar. Muitas vezes eles nem sabem o que está dentro.
O que agora é interessante para os engenheiros de DevOps? A equipe de super-heróis - o comitê do programa da conferência DevOops - caiu em uma armadilha diabólica no Hangouts e respondeu a perguntas por uma hora. (Quem são todas essas pessoas - escritas
em detalhes
aqui ).
Sob o corte - uma entrevista, colorida com giz de cera. Cada especialista tem sua própria cor:
Baruch, o que você acha que aconteceu no mundo desde os últimos DevOops? 
Parece-me que o mais interessante, do óbvio, é a decolagem do Kubernetes em todos os campos e do consumismo não-óbvio - menos perceptível, mas não menos importante, da janela de encaixe. 
Ou seja, antes do docker não era para todos?
Não. Docker costumava ser uma coisa legal e jovem por si só. E então, de alguma forma, a janela de encaixe deixou de ser interessante, ou seja, está lá, todo mundo e tudo o que tem, tem todos os microsserviços, Kubernetes, devops, tudo, qualquer coisa. Mas a própria janela de encaixe, como tecnologia, repentinamente, uma vez e outra, não interessa mais a ninguém. Não execute o mesmo Java nos servidores, é claro que os contêineres. Isso realmente me fascina.
As pessoas geralmente discutem com o que têm problemas ou tarefas diretas. Não houve problemas na janela de encaixe e eles estavam lá?
Havia muitos problemas na janela de encaixe e eles realmente foram resolvidos. Além disso, paramos de usar as partes da janela de encaixe que eram dolorosas. O estivador tinha coisas que ele pode fazer muito bem. E há aqueles que são ruins.
Dê um exemplo.
Por exemplo, prisões em processos unix - tudo é muito bom e inteligente lá. Realmente funciona muito legal. Mas, por exemplo, a conectividade entre microsserviços executados em contêineres, clusters, implantações, foi um inferno e um pesadelo.
Você quer dizer o enxame que eles tentaram acompanhar os Kubernetes? 
Sim, quero dizer Compor, foi tudo um pesadelo e inferno. E decidimos não usá-lo, mas apenas o que funciona bem, o que é compreensível e gratuito. E a janela de encaixe ficou muito legal por um lado e, por outro lado, deixou de ser interessante. Docker e docker - muito bem.
Agora, quando você olha para um novo software, primeiro olha se existe um contêiner pronto. De preferência do fabricante deste software. Então você observa como desdobrar e cutucar com uma varinha. O Docker nos forneceu serviços complexos para cutucar uma máquina em funcionamento. Agora não é tão importante se você é papoula ou Linux. O mesmo Sentry consiste em 5-6 componentes nos quais você começa a se deparar separadamente. E se você tiver uma tarefa apenas para ver como isso é bom, envie um sinal e observe como ele se decompõe lá. Agora levará 15 minutos - ele foi lançado, implantado e a peça estará em Ruby, a peça em Java, que Deus permita, alguma pesquisa elástica - que morrerá com a mesma janela de encaixe.
Mais importante, ele morrerá mais tarde. 
Sim, este é um encanto separado. Anteriormente, era possível falsificar-se no sistema para que em / usr / local não houvesse nada. E ainda aparece - alguém em / opt, alguém em / usr / local, outra pessoa em algum lugar. E o seu sistema aumenta, transborda com tudo o que é desnecessário. Este é um, e o segundo - quanto mais desnecessário você tiver, maior o vetor de ataque contra você, por causa do qual você pode ser ofendido. E como agora estamos lançando tudo isso nas janelas de encaixe, a segurança e a limpeza aqui não carregam nada de ruim conosco.
Escutem, senhoras e senhores, vocês estão fazendo conferências sobre devops, e se o estivador se tornar chato e desinteressante, e agora, não haverá mais estivador?
Em primeiro lugar, o docker estará em todo lugar. Só porque se tornou chato e desinteressante, não significa que deixará de ser usado. Pelo contrário, isso significa que agora estamos usando e não estamos prestando atenção. Ou seja, ele está em todo lugar. Não é um tópico para uma discussão separada em conferências.
Ele tem algum relatório? Se eu entrar no programa agora e escrever a palavra janela de encaixe, não haverá nada?
Escreva. Vamos fazer esse maravilhoso experimento.
Escreveu e diz: Etapas práticas para proteger sua implantação de contêiner
Isso reflete o fato de que o docker permite que nossos sistemas modernos sejam mais seguros de maneira natural. Além disso, reflete mais uma coisa, que também pode ter mudado recentemente ... O Devops se tornou mais. Digamos que as grandes empresas começaram a penetrá-las cada vez mais. E com eles, mais e mais discussões começaram sobre o tema da segurança, que pode ser trazido pelos devops ou, inversamente, para quebrar essa segurança. O relatório de Liz é sobre como preparar adequadamente esse devo para manter seus guardas felizes. 
Você conhece pessoalmente os palestrantes? Quem é Liz Rice?
Liz é uma figura importante na paisagem devopiana. Ela é a chefe de todos os KubeCons. De fato, Liz, em primeiro lugar, é um orador muito bom. Em segundo lugar, ela trabalha para a Aqua Security, uma empresa que lida com segurança de contêineres. Não encontraremos uma pessoa melhor para a história sobre segurança de contêiner do que aqueles que estão especialmente envolvidos nisso. O que é interessante especificamente sobre os relatórios de Liz, vi muitos de seus relatórios, é que ela está tentando resolver um problema bastante complicado. O problema é que hoje a segurança é, primeiramente, complexa e cada vez mais complicada, à medida que os ataques se tornam mais sofisticados. Assim, fica mais difícil se defender contra eles, precisamos criptografar nossas informações no REST, criptografar no tráfego, todos os tipos de TLS, https, certificados, protocolos ... tudo isso é complicado . Com a letra A no final. Em primeiro lugar, é difícil e, em segundo lugar, não há como fugir disso, porque você não pode dizer agora: "Oh, eu não sei disso, vamos lá, não vou fazer https. Bem, quem se importa com quem eu preciso ". Como o mesmo e desprezível Chrome gritará imediatamente a todos os seus usuários que tudo não está seguro com você. E essa combinação de complexidade e necessidade, congela, porque não é nossa preocupação, nem todos estamos seguros. Por outro lado, está conosco, porque não podemos simplesmente ignorar esses aspectos. Liz em seus relatórios tenta transmitir de maneira simples e clara os principais aspectos da segurança de contêineres para pessoas que estão longe da segurança, e isso é muito legal.
Há outro problema que as pessoas arrastam recipientes para a boca de qualquer lugar. Muitas vezes eles nem sabem o que está dentro. Uma coisa é se você quiser colocar sua varinha no seu laptop. E outra coisa é arrastá-lo para a produção. E, infelizmente, muitos arrastam o que quer que seja. Ou seja, você precisa de algo difícil de montar, eles levam o acabado e bem, se for do fabricante, que cuidou e levou os contêineres da base normal. E esse é o mesmo vetor de ataque. Por exemplo, em um futuro próximo, podemos juntar uma nova onda de contêineres com o mesmo nome, como foi o caso dos módulos pip, com módulos get. Como nos domínios, tudo é igual. Ou seja, este não é um problema novo, ainda é o mesmo de sempre. E quando um serviço se torna mercadoria, quando é distribuído, chegam pessoas que punem quem não monitora a segurança. A propósito, por causa disso, temos muitos relatórios sobre segurança.
O que mais existe?
Ainda temos sobre o gerenciamento de segredos de Seth Vargo. A propósito, haverá uma mesa redonda sobre segurança com ele.
Seth é a mesma pessoa do Google que trabalhava na HashiCorp?
Antes disso, ele trabalhou na Chef Software e foi uma estrela lá quando Chef estava no auge da popularidade. Ele deixou uma marca em quase todos os livros de receitas. Alguns nem sequer gostaram dele para esta atividade. Então ele herdou muito na HashiCorp. E este trem HashiCorp ainda se estende atrás dele. Aqui ele vai falar sobre o produto HashiCorp. Ele não vai falar sobre o Google. Mas no título ele terá o Google, então isso adiciona peso.
A propósito, o que aconteceu com o Chef?
Em alguns lugares, o Chef foi morto pelos próprios recipientes.
Os aplicativos de chefes em que foram escritos e funcionam - até onde eu entendi, podem continuar funcionando por um longo tempo, porque o gerenciamento de configuração em si não morreu.
Gente, posso lhe dizer com um exemplo vivo. Temos algo que não está na janela de encaixe e depois no Chef. Porque os server-snowflakes não foram a lugar nenhum.
Você acabou de dizer o que aconteceu com o chef. Aquilo que não está sob a janela de encaixe está sob o Chef. Mas no Docker, temos quase tudo.
Tudo está correto, mas ainda existem servidores de longa duração, servidores com dados que ninguém quer usar. Aqui eles ainda moram com o Chef por algum tempo, porque todo mundo que está em um mundo normal não quer voltar à arena de controle manual.
A propósito, alguém está usando o Ansible?
Sim, Ansible também está lá.
Nós estamos usando.
E como Por que Ansible?
Incrível capacidade de se transformar em lixo em alta velocidade. Esta é a impressão que Ansible deixa. Eu nunca encontrei essa convergência para o inferno na minha vida.
Parece que temos um relatório sobre isso!
Exatamente. E isso ajuda não apenas a transformar o resultado do trabalho com a Ansible no que mencionei. E isso é incrível, desculpe, eu não o vi quando escrevemos isso é tudo de bom .
Você diz que tudo começa sob a janela de encaixe, mas os próprios servidores precisam ser configurados de alguma forma para executar o hipervisor neles?
Não, você pega na Amazon ...
Ah, trapaceiro, na Amazônia. Eu vejo.
Ou Terraform - em qualquer lugar.
O mais avançado. E sobre isso também temos um relatório .
O Terraform fecha essa necessidade, que haja um monte de fornecedores, suas máquinas virtuais iniciam de maneira diferente e você usa o Terraform para fechar a camada quando sua máquina aparecer. Então você tem algum provisionador no Terraform, o mesmo Chef, o mesmo Ansible. Algum provisionador derrama a próxima camada e, em seguida, o Docker voa para essa máquina mínima pronta. Lucro
E o relatório é liderado pela pessoa que fez o aws-modules para o Terraform?
Ele fez muito pelos módulos da Amazon, mas isso faz parte da comunidade. E essa pessoa também é interessante da seguinte forma: desde que ele vive com a Terraform há muito tempo, algumas boas práticas se formaram na comunidade em que ele viveu todos esses anos, e essas melhores práticas simplesmente não são suficientes em torno da Terraform, porque em lugares é tão simples e tão simples. não permite que você faça movimentos desnecessários, que às vezes a descrição é muito complicada. Você terá um calçado ou vice-versa, uma estrutura interconectada muito complexa. E esperamos que Anton Babenko, que estará falando sobre tudo isso, ajude a descobrir como viver com a Terraform e não sofrer com isso. Como desenvolver seus módulos para necessidades pessoais, para que continuem limpos, legíveis e, a propósito, lá, é claro, também ninguém testa nada.
Ninguém tentou esses pés de terraform a partir de uma linguagem de metal mais conveniente para gerar?
Existem essas idéias. E tentamos não fazer isso. Ali, o Terraform possui estruturas de dados que ainda podem ficar sem geração, mas é difícil. Imagine que você tem vários vpc na Amazônia em diferentes regiões, é necessário observar entre eles e aqui começa a aventura. Em cada região da API, o ponto de entrada é diferente, e Terraform você está falando sobre um. Ou seja, você precisa resolver esses pontos de entrada na descrição, descrever cada vpc e também emparelhar, a conexão entre esses vpc em diferentes regiões. E tudo isso deve ser descrito de alguma forma. Nossos caras fizeram isso com seus módulos, e com isso, pelo menos de alguma forma, tornou-se possível viver. Em geral, difícil, difícil. Mas se o Terraform deu ainda mais possibilidades, se houver ... Como é chamado quando a variável dentro da variável é aquecida?
Kotlin DSL. 
<todo mundo ri infernalmente>
Variável variável ou interpolação - dependendo do que você quer dizer.
Em geral, este não é um idioma completo, é muito truncado. Ele faz você escrever da maneira mais simples possível, diferente da DSL Kotlin, onde você tem uma Kotlin completa em suas mãos.
Bem, como, com todas as limitações do DSL Kotlin, que você entende, são resolvidas por quê?
O que?
Groovy DSL resolvido naturalmente!
Muitos usaram o TeamCity dos presentes aqui?
Sim claro. Groove DSL, Kotlin DSL, temos um relatório sobre isso!
E é claro que você faz isso?
Não sou eu, não! Teremos apenas o TeamCity com o DSL Kotlin e sua comparação com o DSL Groovy em Jenkins.
Alguém do JetBrains chegou?
Não. Este é um charme separado.
Temos usuários reais, sem marketing.
Todo mundo, desisto, quem mais pode fazer um relatório sobre o TeamCity?
Uma pequena empresa, amplamente conhecida na Rússia como Tinkoff, usa. Aqui, ele está no programa .
Sim, e conte um pouco, compare com todo o odiado, mas universalmente usado Jenkins e seu DSL Groovy.
Devemos ir, ouvir e descobrir qual o papel do carisma de Baruch na escolha da tecnologia.
Nenhuma. Eu abstraí completamente disso tudo. Tudo será honesto, sem muhlezh.
Quero dizer que Tinkoff adotou todas essas tecnologias modernas por um motivo: o TeamCity não é um tipo de empresa vinte anos atrás, como é habitual nos bancos.
O Tinkoff é um banco que o fez desde o início. Banco para descolados de descolados. Por conseguinte, as tecnologias lá são frescas e corretas.
Pessoal, eu realmente uso o TeamCity todos os dias e, na versão mais recente, ficou ótimo. O TeamCity DSL já está disponível. Veja qual foi o problema da versão mais recente. Na versão anterior, se você alternasse para o Kotlin DSL, não tinha opção para continuar usando a interface. Assim que você cruzou a linha, a única maneira de escrever mais era apenas no Kotlin.
Isso é tudo, você pisou no lado escuro.
Sim, havia um mínimo de documentação, e foi um incômodo. Então, tentamos e voltamos à configuração XML. Na versão mais recente, quando você muda para o Kotlin DSL, continua usando a interface da Web, e ela forma patches sob o capô, corrige essas estruturas diretamente no repositório. Em seguida, você pode continuar escrevendo com segurança no Kotlin, se você já domina algo em algum lugar. Aqueles que ainda não são dedicados podem continuar bisbilhotando na interface. Isso é ótimo, pessoal!
Esta é a influência benéfica de Anton Arkhipov.
A propósito, todos os tipos de práticas foram mencionados aqui. Temos algum relatório dedicado não ao ajuste, mas a alguns processos, cultura e lado humano?
Naturalmente. Em primeiro lugar, temos uma maravilhosa palestra de encerramento de Sasha Titov e Kirill Tolkachev, na qual eles discutirão se tudo está ruim no devoop ou se ainda há esperança. 
Parece-me importante dizer que o DevOops provavelmente é atualmente a única conferência profissional organizada pelo Grupo JUG.ru, na qual é permitido falar sobre coisas sociais e de processo, e no nível oficial.
Para fazer isso, tivemos que conversar de perto com a gerência do grupo JUG.ru, mas o resultado é pessoal.
Além desta bela palestra, também temos um relatório da Dell EMC, que também tem muito a ver com processos. Trata-se de uma equipe dentro de uma empresa que cria serviços para uso interno. Uma coisa é escrever esse serviço e outra começar a usá-lo, porque todas as pessoas estão ocupadas e não têm tempo para dominar as tecnologias modernas. Assim, escreva um serviço e depois venda-o dentro da empresa. Os usuários chegarão até você, todos os tipos de necessidades fora do padrão começarão a surgir, e aqui você tem um dilema: desenvolver um serviço para que muitos possam usá-lo ou satisfazer essa equipe em particular. Também esperamos uma luz lá.
Haverá uma descrição de uma história terrível de dois anos, que não é mais tão doente como era no começo.
Baruch, você também está dizendo algo altamente social?
Lenya Igolnik e eu temos um relatório sobre como começar a medir agora. Essa é toda a desgraça que ocorre em nossos devops. Naturalmente, temos algum tipo de métrica para a qual trazemos conosco do dev e que não usamos e nunca usamos. Temos métricas para as quais trazemos conosco das operações, com as quais sempre foi muito melhor. A questão é: o que exatamente são métricas de devops? O que isso significa? É apenas pegar aqueles e pegar outros, ou é algo novo, algumas novas métricas? Em resumo, devops controlados por dados .
Baruch, às vezes leitores, visitantes fica indignado que os camaradas do comitê do programa estejam lendo seus relatórios, consideram isso algo desonesto.
Realmente levamos tudo isso em conta. Pelo menos, estamos tentando arduamente trazer o maior número possível de oradores, que não são apenas do comitê do programa. Mas, ao mesmo tempo, ainda queremos ver alguns participantes do PC como oradores. Por exemplo, Alena Prokhorchik, engenheira principal do Rancher Labs, que provavelmente tem a maior experiência do mundo com implantações multicloud do Kubernetes. Acho que todo mundo quer ouvir sobre isso, e ela tem algo a dizer . E nós, como comitê de programa, desfrutamos de sua experiência na avaliação de relatórios. Provavelmente, quando toda a conferência é composta por palestrantes do comitê do programa e cada um deles tem cinco relatórios, isso realmente não é bom. Mas se temos um bom palestrante que deseja ajudar o comitê do programa, sinceramente não entendo por que devemos escolher um ou outro.
Baruch, você trabalha no trabalho, além de viajar constantemente com relatórios, além de trabalhar no comitê do programa. Você tem alguma vida? Como você consegue fazer tudo?
O voluntariado para conferências do grupo JUG.ru é muito agradável, porque dá muito prazer - e, além disso, estou aprendendo um novo. Gerar relatórios de pessoas que sabem muito mais do que eu é muito útil.
Eu vejo. Alguém quer acrescentar algo ao nosso monólogo com Baruch?
Costumo dizer que ouvi relatos que ninguém nunca ouvirá .
Sim, o comitê do programa ouve não apenas o que chega à conferência. A competição foi uma em cada três. Podemos dizer que isso aconteceu, porque entre as aplicações havia muitas bastante interessantes. Parte do que filtramos, recomendamos em outras conferências.
Houve algum tópico que você teve que filtrar por quantidade? Kubernetes, por exemplo. Existe mais alguma coisa?
Monitoramento Tivemos uma batalha pelo monitoramento.
Um monte de relatórios. Todo mundo gosta de monitorar.
Quem ganhou este rei da colina?
Alexey Kirpichnikov, relatório “O que aprendemos enquanto criamos nosso próprio sistema de notificação de emergência” .
Existe algo que eu gostaria de ter no programa, mas nenhum especialista?
Você tirou a língua. Há um outro lado da moeda, nosso amado sem servidor, que parece estar sob hype, mas ninguém que pensa bem e praticamente aplicou tudo isso não apareceu. Espero que consigamos pelo menos um. Mas, em geral, as empresas têm pouca experiência industrial. Baruch, e os especialistas evangélicos? Eles também não estão lá? Ou simplesmente ninguém veio até nós?
Toda a história do visto realmente estragou a situação para nós de várias maneiras, inclusive com advogados de desenvolvedores que queriam falar sobre servidor sem servidor, especificamente da Amazon, sobre lambdas. Infelizmente, nos vistos tudo parou.
E houve relatos em que você realmente aprendeu algo novo para si mesmo, que não possuía antes? Ou algumas coisas inovadoras que você lembra?
Eu, como uma das pessoas mais não técnicas do comitê do programa, descubro constantemente um monte de coisas novas que trago aos meus engenheiros mais tarde, e elas dizem que é o que você trouxe para mim. Mas nem sempre!
Tatyana, você não disse nada, me diga, o que aprendeu de novo no processo do PC?
Provavelmente, em quase todos os relatórios, encontrei muitas coisas interessantes que não ouvi. Às vezes menos, às vezes mais. A partir de alguns relatórios, pegamos algo bom para nós mesmos. Especialmente aquele que está associado ao Ansible , que já foi mencionado. Também temos Ansible e também começamos a cozinhá-lo incorretamente. É interessante ouvir o relatório de Oksana , porque trabalho em um departamento que faz algo semelhante. Mas temos uma orientação um pouco diferente: até onde eu sei, o departamento de Oksana lida com aqueles que os procuraram e aqueles que os negócios exigem. Nosso departamento, pelo contrário, está tentando processar todos os que estão na empresa.
, , . , , . .
.
?
. . , , , .
stateful , -, .
, . managed PostgreSQL … , - , — . , , , .
, - , . , ?
. Kubernetes , , . , , - , .
, . - , ? - , - , ?
— . , , , . , ( — , ) — , . JUG.ru Group , , . , , . . , (BOF). , , SRE. security, — , , , , . , , , -, , — , , :-)
- ?
, .
« , , » — , .
?
, , , . .
, , , - Java Virtual Machine, BOF . , , , - .
JVM, , , . , , , .
, — , , . , .
, . DevOops , . . , people + processes, , , .
, , TechTrain, .
, . , , , , . , TechTrain, . , TechTrain . JUG.ru Group, — . , . , . , , , .
, , — « » ( ).
, . -, , , . — , .
DevOops !
, , Joker , Java . , , — .
, , , DevOops - . , every company is a software company, - .
Obrigado a todos pela entrevista! Nos encontraremos com você muitas vezes na preparação de artigos, mas com nossos leitores, nos encontraremos com Habr apenas no DevOops. Tudo de bom, e até breve!
A Conferência DevOops será realizada em 14 de outubro de 2018 em São Petersburgo. Se você gostou do programa que discutimos aqui de repente , não deixe de vir. Os ingressos estão aqui .