#docker #containers #deepDive #devops

Управление окружением - это супер важный процесс в жизни разработчиков. Docker - это возможно самый популярный действенный способ делать это элегантно.

Решил написать серию статей на тему Docker и выложить статьи на Medium.

Планирую написать немного о том как работает Docker Engine, о том как работать с сетями и хранилищами. Как управлять кластером через Swarms и немного о Security.

Пока же написал об Architecture и о том, что такое Image, Container, Swarm and Service.

https://medium.com/@yeldos/docker-deep-dive-689631ac2c97

#DeepDive #aws #networking #myTechNotes

Note 1.

Из простого в AWS Networking, чтобы научить instances общаться между собой внутри одной Подсети используется Layer 2 Data Link (OSI Model), а для общения с внешним миром или между Подсетями, Layer 3 Networking.

В зависимости от кейса, мы подключаем и настраиваем нужный для нас эллемент: Subnet (switches) для общения внутри подсети, router/igw - между подсетями и со внешним миром (Global internet).

#myTechNotes #concurrency #DeepDive

Note 2.

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

Вроде бы все хорошо, тепло и спокойно. Но мне, как ни странно, начали лезть в голову мысли о том, что я не до конца понимаю что такие Concurrency. Крейзи, правда? В общем, вчерашний вечер потратил на то, чтобы лучше разобраться в этом всем.

Я не до конца понимал как работают thread-ы (Потоки/треды). Раньше было понимание, что треды исполняются как то параллельно, что и дает нам ускорение вычислений. Но что меня смутило, так это то, что Треды у нас находятся внутри одного процесса, и выполняются на одном процессоре. А раз так, то откуда мы получаем ускорение, если процессор не может выполнять более одной инструкции в один момент времени.

Как оказалось, у устройства процессов, тредов, и корутин очень много общего. ОС постоянно бегает по всем процессам и постепенно продвигает их вперед. Все происходит настолько быстро, что человеческому глазу ничего не видно. Через какое то время умные люди придумали использовать треды, чтобы не переключаться между тяжелыми процессами. Переключение между тредами происходит намного быстрее, так как часть контекста они разделюят друг с другом, памяти выделяется меньше, и подмены переменных происходит меньше. Корутины - эта та же самая идея, когда Runtime проверяет в цикле доступность отдельных процедур, продвигая их вперед. Это еще более мелкая абстракция, которая работает внутри одного треда.

Откуда же приходит ускорение и в каких случаях?

Я в очередной раз убедился в том, что Concurrency works best with I/O bound tasks. Если при определенной процедуре CPU ничего не делает (is Idle), а просто простаивает (например, спит, ждет ответа от запроса к сайту, или ждет когда подгрузятся данные), то ничего полезного не происходит. Таким образом, мы можем "попросить" программу пойти дальше, чтобы исполнить что-нибудь другое в программе (другую корутину/тред).

С другой стороны, в случае же с CPU Bound tasks, наш процессор работает на всю мощность и переключаться между контекстами Корутин огромного преимущества не дает.

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

Я уверен, что я еще буду возвращаться к этой теме в будущем, с performance tests и более сложными use-cases. Также хочу посравнивать concurrency модели в Golang, Python, и Kotlin. Но, на пока, более чем достаточно.

Если тебе тоже интересно почитать на эту тему и не хочешь тратить много времени на поиск полезных ресурсов, то рекомендую след:

Очень крутой, простой, и короткий курс на Coursera:
- https://www.coursera.org/learn/golang-concurrency

И статьи
- https://www.reddit.com/r/golang/comments/ddc1j3/what_is_the_point_of_concurrency/?sort=top
- https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/
- https://medium.com/@ankur_anand/illustrated-tales-of-go-runtime-scheduler-74809ef6d19b

__Если у тебя есть чем поделиться, дополнить, поправить, пиши, смело!__

Начинаю путаться в тэгах. Пиню для себя и других

Про жизнь в Амазон: #LifeAtAmazon

Architecture:
#systems #design #architecture #systems_design #db #distributed

Language specific:
#python #go

Other:
#ML, #myTechNotes, #DeepDive

About interviews:
Время от времени, преимущественно во время отпуска, провожу Mock интервью.
Все, связанное с интервью, выкладываю по тэгам: #interview #mock #systems_design

Если у тебя будет скоро интервью и тебе нужен Mock Interview, то можешь написать, мне. И если у меня будет получаться по времени, то сможем организовать. Имей в виду, что mock интервью я записываю на видео и выкладываю для других. Также рекомендую посмотреть предыдущие записи, чтобы не допускать примитивные ошибки: https://www.youtube.com/playlist?list=PL3tja-7IZ-wXHY-lvb32-zGnRJaS5yCkU

#myTechNotes #aws #network #DeepDive

Note 3.

Продолжаю копать тему сетей, чтобы не работать со всем этим как с black-box.

Поигрался с AWS VPC:
- Private Subnet для сервков с приложениями
- Public Subnets с bastion host, чтобы запрыгивать через ssh на серваки с приложениями
- NAT Gateway, чтобы позволить ходить из сервков с приложениями в интернет за обновлением софта
- Routers, чтобы поставить коммуникацию между Subnets
- Internet Gateway, чтобы можно было ходить в интернет,

И самое главное, накинул на это все несколько Network Access Control Lists Rules, дабы обезопасить доступ к тому или иному сервису.

Проблема:
Проблема наступила когда я пытался подключиться через ssh без открытия обратных ответов к ephemeral ports моей домашней машины. Вроде бы указал, чтобы TCP трафик на порт 22 ходил в обе стороны (т.е. Outbound, Inbound traffic). Но не тут-то было...


Learnings:
До 2021 я не особо задумывался как происходит подключение через ssh, https, etc, с точки зрения портов на машине клиента. Пришлось поразбираться и я обнаружил (сейчас уже конечно это кажется очевидным), что при отркытии TCP соединении клиент использует один из ephemeral портов, чтобы получать ответы от сервера. Это позволяет нам открывать сразу несколько соединений с сервером как для ssh (Порт 22) так и для http/https соединения (порты 80/443). Открыв ephemeral ports, все сразу завелось!)


Ссылки
Как всегда, делюсь ссылками, которые помогли мне понять все это простым языком. Если тебе интересно и не хочешь тратить время на поиски-и-происки, забирай!

В целом о TCP Ports:
- https://www.youtube.com/watch?v=mykX2YONRwE
О "Well-Known Ports":
- https://www.youtube.com/watch?v=RDotMcs0Erg
Об "Ephemeral Ports":
- https://www.reddit.com/r/aws/comments/cyzzyy/eli5_what_are_ephemeral_ports/
- https://www.whizlabs.com/blog/ephemeral-ports/

Также ниже прикрепляю свой рабочий черновик с диаграммой