Я хочу рассказать история, как запускали приложение в Openshift. Так же по ходу пьесы рассмотрим утилиты для управления приложением внутри Openshift. Это расшифровка выступления на kubernetes SPB meetup #3..

I'd like to share my story about migration an application to Openshift. Also, as a result, I will compare some of the most popular solutions and tools for managing your application inside Openshift. It is the transcription of my presentation at kubernetes SPB meetup #3.

Have you ever noticed that you were busy all day, however, you've done nothing or at X-mas evening you experience an epiphany that nothing was done during the year? If your answer is "yes", you should improve your time management skills. According to Wikipedia, time management is the process of planning and exercising conscious control of time spent on specific activities, especially to increase effectiveness, efficiency and productivity. Nevertheless, how can we deal with it?

One one hand I don't want to be the final authority, but on the other hand, I'd like to share my point of view on how to learn English. The English language is not secret knowledge; it is just a lot of hard training. One of the most important bullets is constantly improving English. You should do it from day to day if you want to approach result. It must not loathe torture for you, It means that you should find out something interesting in that process.

I was putting things in order in a garage, when I found an arithmometer Felix M. It is old school iron gadget, there are no electronics inside.

I'd like to share my story about migration monolith application into microservices. Please, keep in mind that it was during 2012 — 2014. It is transcription of my presentation at dotnetconf(RU). I'm going to share a story about changing every part of the infrastructure.

Monitoring is the most important part of your infrastructure. Monitoring is system engineers basics. However, everyone has his own way to understand it. My way consist of denial. anger & acceptance.

The module was created as a part of my master thesis in the 2010 year. The master thesis theme is Keylogging in Linux kernel. The main idea was to find out a way to intercept system calls for x64 arch Linux kernel, especially for kernel 2.6.34.7-61.fc13.x86_64.

It is text version of the presentation 2018-04-25 at Saint-Petersburg Linux User Group. Configuration example locates at https://github.com/ultral/ansible-role-testing

I suppose that that you make configuration management, not bash. It means that you have to test it some how. Have you ever tested ansible roles? How do you do it?

Это текстовая версия выступления 2018-04-25 на Saint-Petersburg Linux User Group. Пример кода тут: https://github.com/ultral/ansible-role-testing

Полагаю что вы используете configuration mangement, а не bash. Т.е. ваша конфигурация это код. Если мы говорим, что инфраструктура это код, то к её созданию должна применяться та же философия, что и для разработки ПО. Вы задумывались об этом? Как у вас это сделано? А у других?

Russian version

Let's imagine that you are developing software and hardware appliance. The appliance consists of custom OS distributive, upscale servers, a lot of business logic, as a result, it has to use real hardware. If you release broken appliance, your users will not be happy. How to do stable releases?

I'd like to share my story how we dealt with it.

Диспозиция

Представим на минуту, вы разрабатываете программно-аппаратный комплекс, который базируется на своем дистрибутиве, состоит из множества серверов, обладает кучей логики и в конечном счете это все должно накатываться на вполне реальное железо. Если вы впустите бяку, пользователи вас по головке не погладят. Всплывают три извечных вопроса: что делать? как быть? и кто виноват?

Далее по тексту будет история, как начать стабильно релизиться и как к этому пришли. Чтобы не растягивать статью, не буду говорить про модульное, ручное тестирование и все стадии выкатывания на продуктив.

Как начать пользоваться terraform, развернув локально приложение поверх minikube, и потом запустить его поверх kubernetes в cloud.google.com

Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 10 лет работы в IT моё отношение к мониторингу прошло через три стадии:

Отрицание. Ничего не мониторить, пользователи сами сообщат, когда у них возникнут проблемы.
Гнев. Мониторить всё, что можно и нельзя, оповещать всех, включая не очень заинтересованных лиц, что на веб-сервере в течение 30 секунд нагрузка на CPU была 95%.
Смирение. Бизнесу пофиг на процессор/память/диски. Его больше интересует, лучше или хуже стало после изменений в инфраструктуре. Надо работать на упреждение.

Под катом — подробности эволюции моего отношения.

Введение

1. Достичь комфортной скорости интернета.
2. Раздавать интернет не только для себя, но и для супруги.