"Kubernetes in all fields!" - an interview with the program committee of the conference DevOops
Previously, the docker was a cool, youthful thing in itself. And then somehow the docker stopped being interesting: he just is, he is at everyone and in everything. On it all the micro services, Kubernetes, devops - anything. At the same time, people drag the containers into their mouth whence they do not get. They often do not even know what lies inside.
What is now interesting for DevOps engineers? The team of superheroes - the program committee of the DevOops conference - fell into a diabolical trap in Hangouts and answered the questions for an hour. (Who are all these people - see for details.) ).
Under the cut - an interview, colored with crayons. Each expert has his own color:
Practical steps for securing your container deployment
This is a reflection of the fact that the docker allows our modern systems to be safer in a natural way. In addition, it reflects one more thing, which may also have changed recently Devops has become bigger. Let's just say that they are becoming more and more imbued with large companies. And with them, there has been more talk about the security that the Devope can bring, or, conversely, to break this security. Liz's report is just about how to properly prepare this devaps, so that your safety personnel are happy.
Do you personally know the rapporteurs? Who is Liz Rice?
Liz is quite an important figure in the Devasque Landscape. She is the head of all KubeCons. In fact, Liz, first, a very good speaker. Secondly, she works in the company Aqua Security, which deals with the security of containers. The best person for a story about the safety of containers, than the one who specifically deals with this, we will not find. What is interesting specifically about Liz's reports, I've seen many of her reports, is that she is trying to solve a rather complex problem. The problem is that today security, firstly, is complex, and it becomes more complicated and complicated, as the attacks become more sophisticated. Accordingly, it becomes more difficult to defend against them, we must encrypt our information on REST, we must encrypt in-traffic, all sorts of TLS, https, certificates, protocols all this is is complex . With the letter A on the end. Firstly, it is difficult, and secondly, it can not be avoided because you can not say right now: "Oh, I do not know this, let's not do https. Well, it does not matter who needs me. " Because the same vile Chrome immediately screams at all your users that you're not all secure. And this combination of complexity and necessity, it freezes, because it is not our concern, we are not all safety. On the other hand, it lies with us, because we can not just ignore these aspects. Liz in his reports tries simply and understandably to convey key aspects of container security to people who are far from safety, and this is very cool.
There is one more problem in that people are dragging containers into their mouth whence they do not get. They often do not even know what lies inside. It's one thing if you want to stick your wand on your laptop. And another thing - to drag it into production. And, unfortunately, many dragging that no matter what. That is, you need something that is difficult to assemble, they take the finished and well, if from the manufacturer who took care and took the normal base containers. And this is the vector for the attack. For example, in the near future we can scratch a new wave of the same containers, as it was with the peep modules, with the get-modules. As it was with domains, everything is the same. So this is not a new problem, it's still the same old one. And when the service becomes a commodity, when it so spreads - people come there who punish those who do not monitor security. By the way, because of this we have a lot of reports about safety.
And what else is there?
We still have about managing secrets from Seth Vargo. By the way, there will be a round table on security with him.
And Seth is the same person from Google, who used to work in HashiCorp?
Before that, he worked for Chef Software and there was a star when Chef was at the height of popularity. He left a trail in almost every kukbuk. Even some did not like him for this activity. Then he has a lot of heritage in HashiCorp. And this train of HashiCorp for him is still dragging on. He will tell us about the HashiCorp product. About Google, he will not tell. But in the title he will have Google, so it adds weight.
By the way, what happened to Chef?
In some places Chef was killed by those same containers.
Chef applications where they were written and working, as far as I understand, can continue to work long enough, because configuration management itself has not died.
Guys, I can tell you on a live example. We have something that is not in the docker, then under Chef. Because the server-snowflakes did not disappear anywhere.
You just said what happened to Operations. What is not under the docker, then under Chef. But under Docker we have almost everything.
All right, but still there are long-living servers, servers with data that no one wants to shove. Here they will still have some time with Chef live, because in the hand of manual control to return to everyone who has visited the normal world, do not want to.
By the way, does anybody present use Ansible?
Yes, Ansible is also there.
And How? Why Ansible?
Delightful ability to turn into garbage with wild speed. Ansible leaves such an impression. Such convergence to hell, I have not met in my life.
It seems that we have a report on this!
Exactly. And it helps just not to turn the result of work with Ansible into what I mentioned. And it's amazing, I'm sorry, I did not see it when we were writing all this good .
You say that everything under the docker is launched, but the server itself, to start the hypervisor on them, they must somehow be configured?
No, in the Amazon you take
Ah, cheater, in the Amazon. Clear.
Or Terraforma - anywhere.
The most advanced. And about this we also have a report .
Terraform closes this need, that there are a bunch of providers, they have differently started virtual machines, and you are using Terraform to close the layer when your machine appears. Then you have some provisioner in Terraform, the same Chef, the same Ansible. Some kind of provisioner pours the next layer, and then the Docker arrives at this minimally ready machine. Profit.
And the report is led by the person who did aws-modules for Terraform?
He did a lot for the Amazon modules, but this is a community-part. And this person is also interested in the following: since he lived with Terraform for a long time, in the community where he hangs all these years, some best practices have formed, and around Terraform these best practices just do not suffice, because in places it is so simple and so does not allow you to do unnecessary movements, that sometimes the description turns out to be too complicated. You will have either a handkerchief, or vice versa, a very complex interconnected structure. And we hope that Anton Babenko, who is just will tell about all this, will help to lay out on the shelves, how can one still live with Terraform and not suffer from it. How to develop their modules for personal needs, so that they continue to remain clean, readable, and, incidentally, there, of course, also no one tests anything.
Nobody tried these Terraform's footcloths from a more convenient metalanguage?
There are such ideas. And we try not to do so. There, in fact, Terraform has data structures that allow you to still do without generation, but it is difficult. Imagine that you have several vpc in different regions in the Amazon, you need peering between them, and here you have adventures. In each region of the API, the entry point is different, and Terraform seems to be talking about one. That is, you need to break down these entry points in the description, describe each vpc and another peering, the connection between these vpc in different regions. And all this must be described somehow. Our guys did it with their own modules, and with this, at least somehow it became possible to live. In general, it is hard, difficult. But if Terraform gave even more possibilities, if there How is it called when a variable inside a variable is de-allocated?
<все адски смеются>
Variable variable, or interpolation - whichever you meant.
In general, this is not a full-fledged language, it is very truncated. He makes you write as simply as possible, unlike Kotlin DSL, where you have a full-fledged Kotlin in your hands.
Well, with all the limitations of Kotlin DSL, which you yourself understand, are solved by what?
I decideGroovy DSL, of course!
Many people used TeamCity from here?
Oh sure. Gorges DSL, Kotlin DSL, we have the same report!
And of course you do it?
I'm not doing it, no! We will have just TeamCity with Kotlin DSL and its comparison with Groovy DSL in Jenkins.
Did someone come from JetBrains?
No. This is a special charm.
We have real users, no marketing.
All, I give up, who else can make a report about TeamCity?
A small company, widely known in Russia as Tinkoff, uses. Here, in the program it is .
Yes, and a little bit to tell, compare with all the hated, but universally used jenkins and his Groovy DSL.
We must go, listen and find out what role Baruch's charisma played in the choice of technology.
None. I abstracted completely from this all. Everything will be fair, without fuss.
I mean that in Tinkoff they took all these hipster technologies for a reason, TeamCity is not some kind of enterprise twenty years ago, as it usually is in banks.
Tinkoff is a bank that did it from the very beginning. Bank for hipsters from hipsters. Accordingly, the technology there is fresh and correct.
Guys, I really use TeamCity every day, and in the latest version it has become perfect. TeamCity DSL can be used. See what the problem was to the latest version. In the previous version, if you switched to Kotlin DSL, you did not have the option to continue using the interface. Once you crossed the line, the only way to continue writing was on Kotlin.
All, you set foot on the Dark Side.
Yes, there was a minimum of documentation, and it was an adok. So we tried and rolled back at once to the XML configuration. In the latest version, when you switch to Kotlin DSL, you continue to use the web interface, and it creates patches under the hood, patch these structures directly into the repository. Then you can safely continue to write to Kotlin, if you have already mastered something. Those who are not yet dedicated can continue to poke in the interface. It's great, guys!
This is a beneficial influence of Anton Arkhipov.
By the way, here they mentioned all sorts of practices. Do we have any reports that are not dedicated to tuling, but to some processes, culture, the human side?
Naturally. Firstly, we have a beautiful closing keynote of Sasha Titov and Kirill Tolkachev, in which they will discuss whether everything is bad in the devoop or whether there is still hope.
It seems to me important to say that DevOops is probably at the moment almost the only professional conference organized by JUG.ru Group, in which it is allowed to talk about social things and pro process, and at the official level.
To do this, we had to communicate closely with the management of JUG.ru Group, but the result is on the face.
We have, in addition to this beautiful keynote, there is also a report from Dell EMC, there, too, in many respects about the processes. It's about a team inside a company that writes services for internal use. It's one thing to write this service, and another - to start using it, because all people are busy, they do not have time to learn hipster technology. Accordingly, write a service, and then sell it inside the company. The users will come to you, they will begin to have all sorts of non-standard needs, and here you have a dilemma - to develop a service so that many people can use or satisfy this particular team. We are expecting a light there, too.
There will be a description of a terrible two-year history, which is no longer as sick as it was in the beginning.
Baruch, are you also telling something sharply social?
I have a report with Lyonya Igolnik about how to start to measure correctly this is all the disgrace that we have in the devasse. Naturally, we have some metrics to which we bring with us from dev and which we do not use and have never used. We have metrics to which we bring with us from ops, which have always been much better. The question arises, what exactly is the metric of the Devopes? What does it mean? Is it easy to take those and take others, or is it something new, some new metrics? In short, data-driven devops .
Baruch, sometimes readers, the visitors are indignant that comrades from the program committee read their reports, they consider this to be something dishonest.
We really took this all to attention. At the very least, we are trying very hard to bring as many diverse speakers as possible, not just from the program committee. But at the same time we want to see some PC participants as speakers. For example, Alain Prohorchik, Principal Engineer at Rancher Labs, who probably have the most experience in the world with multicloud Kubernetes deployments. I think that everyone wants to hear about it, and she's there is something to tell . And we, as a program committee, enjoy her expertise in the evaluation of reports. Probably, when the entire conference consists of speakers from the program committee, and each of them has five reports, it really is not good. But if we have a good speaker who wants to help the program committee, I honestly do not understand why we should choose either one or the other.
Baruch, you work a job, plus you constantly travel with reports, plus you work in the program committee. Do you have any life at all? How do you manage to do everything?
Volunteering for conferences JUG.ru Group is very pleasant, because it gives a lot of pleasure - and besides, I'm learning new things. Running reports of people who know much more than me are very useful.
Clear. Does anyone want to add something to our monologue with Baruch?
I often say that I heard the reports, which no one will ever hear .
Yes, the program committee hears not only what then gets to the conference. The contest was one to three. We can say that it happened because there were a lot of interesting applications among the applications. Part of what we filtered out, we recommended to other conferences.
Were there any topics that you had to filter by quantity? Kubernetes, for example. Is there anything else?
Monitoring. We had a battle for monitoring.
Pile of reports. Everyone likes to monitor.
Who won in this King of the Mountain?
Alexey Kirpichnikov, report "What we learned while we were making our own system of notifications about contingencies" .
And is there something that I would like to see in the program, but there are no experts?
You took off the language. There is a downside to the medal, our beloved serverless, which seems to be under a HYIP, but nobody who has a good idea and practically applied it all has not appeared. I hope we'll get one out at least. But as a whole, in the companies of industrial experience it is yet small. Baruch, what about the evangelical experts? They, too, no? Or just no one came to us?
All this history with visas we have very spoiled the situation in many ways, including with developer advocates who wanted to come and talk about serverless, specifically from Amazon, about lambdas. On visas, unfortunately, everything died down.
And there were such reports in which you really learned something new for yourself, which was not before? Or some breakthrough things that are remembered?
I, as one of the most nontechnical people in the program committee, constantly learn a bunch of new things, which I then bring to my engineers, and they say, but this is the 101 that you brought to me. But not always!
Tatyana, you did not say anything, tell me what new things did you learn in the process of the PC?
Probably, from almost every report I found a lot of interesting things that I did not hear. Sometimes less, sometimes more. From some reports we took something good for ourselves. Especially the one that is associated with Ansible , which has already been mentioned. We also have Ansible, and we also started to cook it incorrectly. It's interesting to listen to Oksana's report , because I work in a department that does something similar. But we have a slightly different orientation: as far as I understand, Oksana's department deals with those who came to them and those whom business requires. Our department, on the contrary, tries to process all who are in the company.
In fact, no, I'm working in the same department, he's at the same positions. We are officially a large unit, which is entrusted to distribute these services, including by force. We will talk about this at the conference.
And Borodin discussed?
Not yet. Vladimir Borodin talks about database in the clouds . By the way, according to cloud technologies, this is probably the only report we have.
A report on the stateful in the cloud, and it's such a game-game that no one can do.
This nobody wants to do, because nobody potentially wants to lose data. And so the emergence of such managed PostgreSQL in Russia In conditions that many services simply had to some time back to move to Russia, so they were allowed to work further - the appearance of such a service closes the last element of the puzzle. If there were a lot of clouds in Russia, reliable storages that can be trusted are not easy to name.
Baruch, you always listen to something, you tell. Tell me, what struck you the most?
We started with this. I'm very interested in Kubernetes walking around the planet, I'm very interested in the docker's consumerization, it's very funny stuff. And, of course, I, as one of the less technically savvy and less hardcore-oriented representatives of the program committee, really tried to ensure that we did not bypass the topic of culture and the proper construction of processes.
The time allocated for the meeting is rapidly approaching the end, and it's time to sum up. Can you wish something to those who are reading this now? Any final thoughts, any reports that should be looked at first?
A very simple way to join the great is to hang on the live broadcast of the first hall. Naturally, the suitability will not only be in the first hall, accordingly, it makes sense to look at other reports too. But it seems to me that the main difference between viewing reports (including broadcasting - whether it's free or paid) from going to the conference is everything that's going on between them. JUG.ru Group is famous for the activities that take place on the court outside the room itself, where the report takes place. This is the communication with the speakers in the discussion areas, and all the flesh that we prepared after the conference closing. There we have a lot of interesting things. We will have round tables, discussion boobs (BOF). About such sick topics, for example, than devaps differs from SRE. There are technical reports on security, but there is a much more global problem - what should we do with this, because, as I said, none of us are specialists, and we have to do it all. In addition, every fan, for example, will be a karaoke-battles, in which everyone can participate, a gikovsky party - as expected, everyone will stand in the corners, drink and be silent :-)
All those present here can be met or someone does not go?
Most likely, I definitely will not.
"Most likely, for sure, with a high probability" - it's fine, I believe.
Still saw this picture?
Yes, all these words, vary depending on the culture of the country in which it is all pronounced. It's like that.
It is interesting that when it comes to, say, some guts Java Virtual Machine, then BOF turns into another report. Here, most likely, the bofs will be bofs, in which everyone can participate and say something.
It's not the JVM's guts, but the fact that some speakers are abusing the format of the bof to make a report out of it. We, as a program committee, will do everything possible to prevent this from happening.
The idea is that devoops are processes, and this is exactly what you need to grind in the corridors. It seems to me, it should be directly accentuated.
All right, excellent remark. For the DevOops conference, communication on the sidelines is even more important than for all other conferences. I completely agree with you here. Just because these people + processes, the reports fall much worse than on the discussion areas, bofs and everything else.
Probably, it makes sense to emphasize this, because I looked at the same Artem Kalichkin on TechTrain, and the discussion area was comparable in saturation with the report itself.
I agree, I was also in this discussion zone. There after the report, maybe even more interesting than what he was broadcasting to the audience. But what he told on TechTrain, here we would not have gone much. It must be understood that the audience of TechTrain was completely different. This is a new format for JUG.ru Group, this is not a conference - it's a festival. There was a lot of mixed things, it was very cool. I was there both days, and everything was very interesting and good. There were reports, but many of them were live, on the youth audience, to interest and cause discussion.
There would be a sense that the discussion can start with a short report, and then the entire space of the ExpoForum is your "discussion zone" (if to speak in terms of our conferences).
Yes, it was. There were also reports, litting, in the areas near the stands for literally twenty minutes, after which I also happened to be a witness of a report about how a person wrote the battles of Bach. We discussed with him half an hour more - he just was not lucky that I passed by.
Invite him to DevOops next time!
He, rather, on the Joker should be invited, because he wrote in Java. And the person, by the way, from the wonderful company Leroy Merlin is an exclusively IT company.
They do a lot of things, they perform at many conferences and, probably, the next DevOops from there it will be possible to invite someone interesting. You know, every company is a software company, and for sure they are doing something interesting.
Thank you all for the interview! We will repeatedly intersect with you in the preparation of articles, but with our readers with Habra, we will meet only on DevOops. Have a good time, and see you again!
The DevOops conference will be held on October 1? 2018 in St. Petersburg. If you suddenly liked program , which we discussed here, then definitely come. Tickets are by reference .
It may be interesting
visit this site
visit this site
visit this site
Pleasant data, significant and magnificent plan, as offer great stuff with smart thoughts and ideas, bunches of incredible data and motivation, the two of which I need, on account of offer such an accommodating data here.