Новости IT

[• samson2]

На работе на позапрошлой неделе проводили обучение по технологии Docker,
собираюсь провести обучение в открытом доступе через youtube трансляцию. Пока предварительно на 18.30 - 21.30 Видимо будет два дня подряд или через один.
Как точно с датой определюсь, отпишусь здесь.

В планах -
1) знакомство с докер - зачем, как
2) запуск контейнеров из публичных источников
3) свой докер контейнер
4) свой докер контейнер с web приложением на борту (будет простейший питоновский flask)
5) начала работы с docker-compose
6) методики отладки приложения и багофиксинга

Для освоения техники крайне желателен или комп, или виртуалка с линуксом на борту, достаточно ssh доступа к виртуалке.
Что нужно дополнительно установить - напишу здесь не позднее дня до трансляции.

Сообщение отредактировал samson2 - Apr 12 2020, 22:19

[• samson2]

Будет два занятия (одно во вторник 14 апреля в 18.30 - 21.30 и в четверг 16 апреля в то же время) В среду будет время потренироваться перед вторым более активным днем.

Занятие будет проходить в форме мастер-класса - я буду что-то делать, рассказывать, кидать копии команд в чатик, потом давать время на повторение моих манипуляций и отвечать на вопросы.

На подопытную машину надо поставить:
1)
docker,
docker-compose
python
git
любая из этих команд должна выдавать страничку помощи (так можно протестить работоспособность)
2)
дополнительно для питона стоит pip (устанавливается через apt-get install python-pip)
3)
должен быть веб-браузер запускаемый на данной машине - links например

Можно и с виндовой машиной, но там будет куча сложностей с инсталляциями и прочим, есть огромная вероятность что вы чего то повторить не сможете, а я не смогу вам помочь, тк уже давно не на винде и даже рядом не в курсе за проблемы.

Тренироваться будем на простейшем питоновском фрейворке Flask, питон знать не обязательно, кода там будет строк 20, смысл всех команд я объясню.

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

Сообщение отредактировал samson2 - Apr 12 2020, 22:45

[• samson2]

Телеграмм группа - трансляции https://t .me/joinchat/ENJb6BolXoaffQEue4bFZA

(Убрать пробел:) )

Сообщение отредактировал samson2 - Apr 12 2020, 20:37

[• samson2]

Трансляция будет тут:

https://www.youtube.com/watch?v=TcUBqPf6tyo

Мастер-класс использование технологии Docker

[• samson2]

Напоминаю что трансляция сегодня вечером, не забываем, готовим рабочие машинки, потому что упор на практику

В начале минут 15-20 будет теории, а потом сразу перейдём к практике.
Посмотрим как выкачать образ из публичного репозитория, сделаем свой hello-world
Потом сделаем и отладим свой контейнер с web сервисом на борту

План на четверг (16.04.2020) - познакомиться с docker-compose, опять будет сколько-то теории, потом сделаем выкатку "сцепки" контейнеров из публичной репы, затем запуск включая свой контейнер в "сцепку", знакомство с проблемами и отладка.

Обучение которое провожу - базируется на своих "шишках" и наработанных приемах диагностирования проблем.

[• samson2]

Внимание! Старая ссылка испортилась, перед самой трансляцией ссылку обновлю

Новая ссылка:

https://www.youtube.com/watch?v=UmxYCtS5-h4

Прямая трансляция пользователя Алекcей C

Сообщение отредактировал samson2 - Apr 14 2020, 11:56

[• samson2]

Ещё на подопытной машине нужен текстовый редактор, я буду использовать:

nano

[• samson2]

Первая часть - с 9.45

https://www.youtube.com/watch?v=UmxYCtS5-h4

Прямая трансляция пользователя Алекcей C

Вторая часть - с 3.20

https://www.youtube.com/watch?v=sisEFFxCq0U

Мастер класс docker 1-2

Сообщение отредактировал samson2 - Apr 14 2020, 21:43

[• samson2]

Ссылки на второй день:

https://www.youtube.com/watch?v=ECGA9gNrz40

Прямая трансляция пользователя Алекcей C

https://www.youtube.com/watch?v=S2scaDnI2nM

Мастер-класс docker 2-2

Сообщение отредактировал samson2 - Apr 16 2020, 20:22

[• Humanoid]

В планах -
1) знакомство с докер - зачем, как
2) запуск контейнеров из публичных источников
3) свой докер контейнер
4) свой докер контейнер с web приложением на борту (будет простейший питоновский flask)
5) начала работы с docker-compose
6) методики отладки приложения и багофиксинга

Самсон-2, ты заявляешь что контейнеризация позволяет отчуждать одни программы от других в пределах операционной системы. Однако тоже самое отчуждение уже позволяет делать сама операционная система "Линукс" через cgroups. Достаточно лишь назначить права для каждой из программ и прописать путь для подгрузки библиотек для каждой из них.
А в нагрузку с "Докером" ты получаешь большую нагрузку на процессор, оперативную память и диск, что выйдет тебе в большую задержку времени отклика программы на внешние воздействия. Да и ошибки в "Докере" ты сам собрался исправлять? Зачем это совершенно ненужное нагромождение кода в виде якобы удобства? Для кого удобство-то? Для туповатых админов, которые не осилили cgroups?

[• samson2]

Самсон-2, ты заявляешь что контейнеризация позволяет отчуждать одни программы от других в пределах операционной системы. Однако тоже самое отчуждение уже позволяет делать сама операционная система "Линукс" через cgroups. Достаточно лишь назначить права для каждой из программ и прописать путь для подгрузки библиотек для каждой из них.
А в нагрузку с "Докером" ты получаешь большую нагрузку на процессор, оперативную память и диск, что выйдет тебе в большую задержку времени отклика программы на внешние воздействия. Да и ошибки в "Докере" ты сам собрался исправлять? Зачем это совершенно ненужное нагромождение кода в виде якобы удобства? Для кого удобство-то? Для туповатых админов, которые не осилили cgroups?

Как я понимаю ты девопс? Давай рассмотрим ситуацию именно. с точки зрения девопса:

1) Разработчик отдает тебе полностью готовый функционал, который запускается что называется "по щелчку пальцев" - ты только должен передать env-ы.
Если твои разработчики все пишут в dotnet core, девопсеру очень просто, а когда у тебя часть кода доставляется в java, часть кода python, часть кода в react.js, часть кода С#, GO, а ещё есть компоненты системы которые являются open-source программами написанными вообще к примеру на Ruby, а твои разрабы только с конфигами там поработали... И это я не выдумал, это то, с чем реально наши девопсы работают.
2) очень удобно разрабатывать и тестировать, когда у тебя любое нужное тебе приложение разворачивается а потом удаляется без следа - тоже "по щелчку". Т.е. на CI/CD у нас тестовый контур создается под запуска тестов которые запускаются при пул-реквесте на мастер, никаких тебе возможных конфликтов между разными тестами запустившимися одновременно несколькими разрабами.
3) очень удобно для масштабирования - при необходимости ты в любом дата-центре поднимаешь свой контейнер опять таки не заморачиваясь о том - все ли пакеты стоят на виртуалке. А k8s позволяет управлять количеством контейнеров к примеру по количеству запросов.
Это очень похоже на Java jar файлы, только они исполняются не на виртуалке джава, жрущей память, а нативно.

Самсон-2,
А в нагрузку с "Докером" ты получаешь большую нагрузку на процессор, оперативную память и диск, что выйдет тебе в большую задержку времени отклика программы на внешние воздействия.

Нет, на самом деле контейнеризация в докере как раз не дает никакой нагрузки на процессор, оперативную память и тп (либо почти не даёт). Виртуализация докера как раз и построена на фундаментальном свойстве линукса как многопользовательской системы. Изоляция достигается за счет того что каждый докер-контейнер порождает группу процессов, по сути создается "виртуальный пользователь".

P.s. До конца не уверен насчёт нагрузки на память, вот если через k8s рабоать, там точно память резервируется, как и ядра процессоров - там жестко распределение идёт, но в самом docker насколько я понимаю, резервирования быть не должно... тк для линукс все процессы равнозначны, что запущенные в контейнере, что запущенные на хосте...

Сообщение отредактировал samson2 - May 10 2020, 11:53

[• Humanoid]

Как я понимаю ты девопс?

Нет, прислугой пусть работают другие люди. Я не для этого много лет учился.

Давай рассмотрим ситуацию именно. с точки зрения девопса:
1) Разработчик отдает тебе полностью готовый функционал, который запускается что называется "по щелчку пальцев" - ты только должен передать env-ы.
Если твои разработчики все пишут в dotnet core, девопсеру очень просто, а когда у тебя часть кода доставляется в java, часть кода python, часть кода в react.js, часть кода С#, GO, а ещё есть компоненты системы которые являются open-source программами написанными вообще к примеру на Ruby, а твои разрабы только с конфигами там поработали... И это я не выдумал, это то, с чем реально наши девопсы работают.

Ты привёл типовой пример бестолковой разработки, когда в проект тащат несколько языков без надобности. Ведущего разработчика следует гнать в шею за такое попустительство. Из-за такого тупаря проект получит избыточную сложность в удержании работоспособности ПО при изменчивости библиотек и языков в будущем.

2) очень удобно разрабатывать и тестировать, когда у тебя любое нужное тебе приложение разворачивается а потом удаляется без следа - тоже "по щелчку". Т.е. на CI/CD у нас тестовый контур создается под запуска тестов которые запускаются при пул-реквесте на мастер, никаких тебе возможных конфликтов между разными тестами запустившимися одновременно несколькими разрабами.

Не вижу трудостей положить файлы проекта в отдельную папку и запускаться скриптом оттуда.

3) очень удобно для масштабирования - при необходимости ты в любом дата-центре поднимаешь свой контейнер опять таки не заморачиваясь о том - все ли пакеты стоят на виртуалке. А k8s позволяет управлять количеством контейнеров к примеру по количеству запросов.

Что мешает тебе запустить ещё одну копию программы напрямую при возрастании нагрузки? "Докер" тут совершенно не нужен.

Это очень похоже на Java jar файлы, только они исполняются не на виртуалке джава, жрущей память, а нативно.
Нет, на самом деле контейнеризация в докере как раз не дает никакой нагрузки на процессор, оперативную память и тп (либо почти не даёт). Виртуализация докера как раз и построена на фундаментальном свойстве линукса как многопользовательской системы. Изоляция достигается за счет того что каждый докер-контейнер порождает группу процессов, по сути создается "виртуальный пользователь".
P.s. До конца не уверен насчёт нагрузки на память, вот если через k8s рабоать, там точно память резервируется, как и ядра процессоров - там жестко распределение идёт, но в самом docker насколько я понимаю, резервирования быть не должно... тк для линукс все процессы равнозначны, что запущенные в контейнере, что запущенные на хосте...

Чем больше количество строк в программном обеспечении, тем больше в программе имеется ошибок. А чем больше программных прослоек между пользователем и программой, тем дольше время отклика на действие пользователя. Зачем ты споришь с азбучной истиной?

[• samson2]

Нет, прислугой пусть работают другие люди. Я не для этого много лет учился.

Хм... сколько Вам лет? Так оценивать devops...

Ты привёл типовой пример бестолковой разработки, когда в проект тащат несколько языков без надобности. Ведущего разработчика следует гнать в шею за такое попустительство. Из-за такого тупаря проект получит избыточную сложность в удержании работоспособности ПО при изменчивости библиотек и языков в будущем.

У каждого языка есть своя ниша, свои сильные и слабые стороны.
У Python к примеру самая развитая структура фреймворков для обработки данных, С# дает продвинутые возможности взаимодейтствия с windows, глупо на С# или Java писать фронтенд (оптимальный выбор для развитого фронтенда - фреймворк основанный на Javascript) и тд.

Не вижу трудостей положить файлы проекта в отдельную папку и запускаться скриптом оттуда.

Для интеграционного и системного тестирования требуются базы данных, очереди - как минимум, а как правило всякая прикладнуха к примеру - геосервер, экземпляр сетевого файлового хранилища... И если для unit тестирования допустимо это всё заменить моками (что потребует времени на разработку этих моков), то для интеграционного и тем более системного тестирования обязательно нужны реальные системы

Что мешает тебе запустить ещё одну копию программы напрямую при возрастании нагрузки? "Докер" тут совершенно не нужен.

Конечно не нужен. Можно разворачивать из образа целую виртуалку в требуемом регионе. Правда виртуалка сожрет в 10 раз больше ресурсов и будет стоить в 10 раз дороже.

Чем больше количество строк в программном обеспечении, тем больше в программе имеется ошибок. А чем больше программных прослоек между пользователем и программой, тем дольше время отклика на действие пользователя. Зачем ты споришь с азбучной истиной?

На каком языке Вы пишете?

[• Humanoid]

Хм... сколько Вам лет? Так оценивать devops...

Оставим мой возраст за кадром обсуждения. В беседе более важен опыт и знания.

Для интеграционного и системного тестирования требуются базы данных, очереди - как минимум, а как правило всякая прикладнуха к примеру - геосервер, экземпляр сетевого файлового хранилища... И если для unit тестирования допустимо это всё заменить моками (что потребует времени на разработку этих моков), то для интеграционного и тем более системного тестирования обязательно нужны реальные системы

И? В чём именно трудность запускать "реальные системы" напрямую без "Докера"? "Линукс" позволяет держать на компе несколько версий библиотек и баз данных. Разложил всё по папкам, назначил права на доступ и запускаешь скриптами. Не вижу преград кроме человеческой тупости и слепого следования шаблонам. Меньше нужно пропаганды кушать, а больше думать своей головой.

Конечно не нужен. Можно разворачивать из образа целую виртуалку в требуемом регионе. Правда виртуалка сожрет в 10 раз больше ресурсов и будет стоить в 10 раз дороже.

Причём здесь виртуальные машины? Я говорю о запуске программ, отчуждая их друг от друга с помощью управления доступом через cgroups. В целом, я выступаю за упрощение программ и их окружения, потому как чем проще устроена система, тем она надёжнее работает и её проще развивать и поддерживать.

На каком языке Вы пишете?

На разных языках пишу в зависимости от задачи. Я не выбираю язык из-за его технологических преимуществ, а смотрю на рынок труда в первую очередь - что востребовано, то и использую. Это и фреймворков касается.

[• samson2]

Оставим мой возраст за кадром обсуждения. В беседе более важен опыт и знания.
И? В чём именно трудность запускать "реальные системы" напрямую без "Докера"? "Линукс" позволяет держать на компе несколько версий библиотек и баз данных. Разложил всё по папкам, назначил права на доступ и запускаешь скриптами. Не вижу преград кроме человеческой тупости и слепого следования шаблонам. Меньше нужно пропаганды кушать, а больше думать своей головой.
Причём здесь виртуальные машины? Я говорю о запуске программ, отчуждая их друг от друга с помощью управления доступом через cgroups. В целом, я выступаю за упрощение программ и их окружения, потому как чем проще устроена система, тем она надёжнее работает и её проще развивать и поддерживать.
На разных языках пишу в зависимости от задачи. Я не выбираю язык из-за его технологических преимуществ, а смотрю на рынок труда в первую очередь - что востребовано, то и использую. Это и фреймворков касается.

Очень похоже что Вы переоцениваете свой опыт...
Весьма похоже что Вы не работали в разработке web систем, состоящих из десятка разнородных компонентов,
Не работали в компаниях работающих сразу с десятком проектов...

p.s. Вы используете фреймворки - они по вашему не являются "прослойкой"?