Привет, меня зовут Кирилл, я живу в Тель-Авиве и пишу бигдату на JS, а также занимаюсь девопсом на Амазоне.

Раньше писал веб, но теперь пишу только API либо инфраструктурные сервисы, которые бегут в контейнерах время от времени.

У нас есть свой data pipeline, который наша компания к тому же продает в виде сервиса - aws.amazon.com/redshift/partn…

А сколько портов пытались пробросить? @ynelin

У нас везде докер, но не на ECS, а генерация CloudFormation нашим домашним deployment tool

Вообще связка docker-compose + crontab + CloudFormation очень сильна.

У докера куча проблем, но объективно он очень сильно упростил provisioning благодаря изоляции контейнеров друг от друга

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

А хост-систему настраивать остаётся по минимуму, если вообще

Например, наши сервера бегут на Amazon Linux, в большинстве контейнеров CentOS/Debian, нам нужен только Docker daemon и docker compose

Все общие таски типа логов, синхронизации файлов вынесены в отдельные контейнеры

С одной стороны, контейнеризация приносит оверхед и усложнение разработки, с другой стороны с маленькими компонентами работать проще

Предлагаю на неделе обсудить контейнерные технологии, opensource, разработку ядра, конференции, сообщества. Если не против, тогда начнём.

Мы пользуемся схемой blue/green deployment, то есть каждый раз продакшен создаем заново, потом они бегут параллельно, потом старый отключаем

Я считаю, что полная перестройка лучше обновления, потому что нет проблемы отката (который может и не работать)

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

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

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

Ни разу не пожалел, что написал к проекту тесты, а вот наоборот бывало довольно часто. Пишите тесты, это окупается.

Всегда храните время в UTC и не используйте кастомные форматы хранения данных и/или шифрование, это не приносит ничего, кроме проблем

pic.twitter.com/J3xCp5UTEV

@rubyunderhood Ага, бывает что тесты лучше чем проект.

Своя компания - способ максимально быстро избавиться от розовых очков в отношении программистов и сильно ослабить свою веру в людей

“Живая” миграция это миграция контейнера с низким временем недоступности (downtime). Это 1-2 секунды.

Такая задержка в обслуживании, которая не повлечёт за собой разрыв открытых сетевых соединений.

. @rubyunderhood поэтому хостеру нужно перенести контейнеры на другой сервер, чтобы выполнить обслуживание сервера

Если пользуетесь Амазоном, то переводите все сервисы на роли и нормально разбивайте из на policies, которые можно подцеплять к разным ролям

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

И совершенно очевидно, что никогда не стоит привязывать сервисы к ip, а не к security groups - это убивает autoscaling, зачем себе вредить?

Одна из лучших вещей, которую можно сделать с S3 - прицепить event на загрузку/копирование файла; event идет в SQS, забираете и процессите

Относитесь к серверам как к commodity - если вы не можете автоматически поднять копию своего сервиса за 5-10 минут, то у вас что-то не так

На сегодняшний день "живая" миграция в LXC, Docker и Virtuozzo 7 работает с помощью CRIU. criu.org/Integration

Кстати возвращаясь к теме про stateless. Как известно, Docker это stateless. Но были желающие, которым нужна была "живая" миграция в Docker.

Это только подтверждает право на жизнь обоих подходов.

Имелось в виду кастомное шифрование, конечно же. Никогда, никогда так не делайте. twitter.com/rubyunderhood/…

Containers in Dev vs Prod pic.twitter.com/YqDHvigW8r

Как вы связываете свои микросервисы? Мне кажется, что очередь + внешнее хранилище типа S3 - довольно удачный вариант

Ни разу такого не было, но ладно twitter.com/hatarist/statu…

@gaar4ica @rubyunderhood свой надо таскать на работу, это минус. Да и компанию это в большинстве случаев характиризует

@gaar4ica @rubyunderhood из личного опыта, в таких компаниях экономят на всем: нету CI, бомжехостинг в виде одного единственного сервера

Если не читаете на английском художественную литературу, читайте хотя бы журналистику - New York Times, Washington Post.

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

Избегайте компаний, у которых переработки - это часть культуры. Это или эксплуатация, или идиотизм.

Помните, что ваши интересы и интересы работодателей кардинально различаются. Работать за идею в коммерческой организации - абсурд.

Если вы ей не владеете, конечно.

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

@rubyunderhood прекрати правду-матку резать в среду утром! так и хочется домой пойти :)

Лучше пойти в компанию, где ничего нет и есть желание сделать нормально, чем в компанию, где ничего нет и которая не хочет менятся

@jsunderhood сейчас много IoT кода пишется на JS, как минимум на этапе прототипирования

@rainrb @Shiroginne @rubyunderhood на прошлой работе мне вручили галимый леново с i3, такой же я бабушке своей покупал

@rubyunderhood они велики :(

@webholt @iamstarkov @jsunderhood ну это же глупости. Пока в Виларибо ищут, какая падла изменила объект, в Вилабажо уже пьют пиво

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

Если вам нужно сделать какой-то maintenance task, возьмите лучше Python либо генерируйте shell-скрипт своим кодом, а потом отдавайте | bash

Постарайтесь не использовать нигде cp, mv, rm; `find -exec` убирает ограничение на количество обрабатываемых файлов.

@oleg_antonyan @rubyunderhood а, linux у меня вообще чисто с серверной платформой ассоциируется.Как десктоп со 2го гнома там ничего хорошего

Сколько времени у вас занимает provisioning с нуля? У нас минут пять, но это довольно долго. pic.twitter.com/qPMS8dxdHV

А health check у вас проверяет все сервисы? Базу данных, Redis?

Какой Линукс у вас на серверах, кстати? И какой внутри контейнеров? У нас Amazon Linux, CentOS 7/Debian

@rubyunderhood Centos/rhel

Как часто вам приходится расследовать, что происходит внутри вашего data pipeline? У нас много источников данных, поэтому каждую неделю.

@rubyunderhood CentOS

Доброе утро! 🐓 pic.twitter.com/H8ploNHyYa

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

У нас сегодня выходной, поэтому я пойду пить кофе

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

У нас есть дэшборд с сенсорами, в том числе с latency поступления новых данных, мониторинг очередей, дисков.

@rubyunderhood но он должен быть по кнопке (:

До сих пор не потеряло актуальность 12factor.net

Если вы автоматизировали какой-то flow, логи, например - поделитесь с другими отделами