Моя жизненная заметка, где используют TS, зачастую используют не тот язык ;) В данном проекте веб морда и тут все понятно. А вот когда TS мешают с "многокода" на беке зачастую вижу неправильный выбор язык. Проще сразу взять java/go или с++ под оптимайзинги на край. Видел биллинг, блокчейн нодовский который переростал в гошный блокчей и кучу подобных проектов)

TL != TS

Моя жизненная заметка, где используют TS, зачастую используют не тот язык ;) В данном проекте веб морда и тут все понятно. А вот когда TS мешают с "многокода" на беке зачастую вижу неправильный выбор язык. Проще сразу взять java/go или с++ под оптимайзинги на край. Видел биллинг, блокчейн нодовский который переростал в гошный блокчей и кучу подобных проектов)

Что имеется ввиду под TS? TypeScript? TL к ниму не имеет отношения, вроде бы))))

Я увидел .ts файл. Замечу что я не обсераю проект ребят

И говорил про ts

я хоть и не пишу на js, но TS выглядит хорошо когда надо IDE использовать: подсказки, проверка типов, интеллисенс, вот это все

Ну да, типизация и поддержка ide — всегда хорошо

Причем тут размер

Требования у него не такие и мелкие, и вообще ты чо за мезос не топишь

я хоть и не пишу на js, но TS выглядит хорошо когда надо IDE использовать: подсказки, проверка типов, интеллисенс, вот это все

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

@JBaruch учитывая что ваш артифактори у них в Юниверсе

@JBaruch учитывая что ваш артифактори у них в Юниверсе

Мы же универсальные, со всеми дружим

Я с Реем вебинар делал

Мы же универсальные, со всеми дружим

Но ты советуешь кубернетес, который не так просто поднять

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

TS — уже со статической типизацией А для flow и транспайлер может быть не нужен

Но ты советуешь кубернетес, который не так просто поднять

Да ладно, чего там сложного

Да ладно, чего там сложного

Ну открой инструкцию, без бутылки не разобраться

Ну открой инструкцию, без бутылки не разобраться

Ты просто алкоголик и едешь повод выпить

Ты просто алкоголик и едешь повод выпить

Я ж вообще не пью)

TS — уже со статической типизацией А для flow и транспайлер может быть не нужен

Когда не будет такого понятия как Type script compiler, тогда и будет хорошо. А пока JS это язык с динамической типизацией. И все что сверху уже как костыли. Код перегонять из состояния в состояние плохо. Это может делать только оптимизирующий интерпретатор/этап компиляции. В основном это оврехед. Строгая типизация убирает всю эту вазню + делает возможным прогонять код через статический анализатор кода в первозданном виде

На самом деле мезос тоже годнота. Всё, кроме сварма — годнота.

Я ж вообще не пью)

Но и кубернетс еще не настраивал?)

Ну открой инструкцию, без бутылки не разобраться

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

На самом деле мезос тоже годнота. Всё, кроме сварма — годнота.

Мезос более годнота потому что позволяет поставить внутри кубернетес одним нажатием кнопки

Мезос более годнота потому что позволяет поставить внутри кубернетес одним нажатием кнопки

Уговорил.

Уговорил.

И артифактори там ставится тож так , вообще супер. Не ожидал его там увидеть)

И артифактори там ставится тож так , вообще супер. Не ожидал его там увидеть)

Чего это не ожидал?

TS — уже со статической типизацией А для flow и транспайлер может быть не нужен

идеология flow мне нравится. Даже захотелось ее заюзать

Ну вообще да) И у него типизация значительно мощнее Но это всё равно не мейнстрим и путь не для слабых духом 😁

@JBaruch увидет artifactory в mesos universe, думал там только апачевские штуки

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

сварм в три команды ставится ) на каждом инстансе по одной

Можно еще на http://rancher.com/rancher/ посмотреть

Можно еще на http://rancher.com/rancher/ посмотреть

Это тот который нельзя развернуть на 5-ти долларовом DO потому что он только под себя выжирает 2 гига? Или я путаю

@JBaruch увидет artifactory в mesos universe, думал там только апачевские штуки

Wat

Вроде я когда поднимал не 2 гига ел, я его только пощупал

Это тот который нельзя развернуть на 5-ти долларовом DO потому что он только под себя выжирает 2 гига? Или я путаю

на 5$ DO вообще ничего размещать нельзя

😊

тут кто нибудь сварм использует )?

мы сварм мод используем

мы сварм мод используем

там нативный service discovery или все еще нужнен consul?

на 5$ DO вообще ничего размещать нельзя

можно ) откуда такая увереность?

Там ДНС как дискавери работает

То есть можно к контейнерам по имени сервиса достучаться.

Там ДНС как дискавери работает

супер!

В Остине есть кто?

Там ДНС как дискавери работает

для кларификации, там свой сервис дисковери?

Не надо никаких дополнительных сервисов. Делаешь сварм мод, запускаешь, например, сервис из 10 контейнеров, по имени сервиса в докере будет резолвится 10 айпишников. Скейлишь до 5 - будет резолвится 5. То есть он сам следит. Если какой-то контейнер покрашился, докер его перезапустит.

Всем привет! Подскажите пожалуйста, как нужно организовать docker-compose для запуска и разработки нескольких микросервисов, расположенных в разных директориях? Заранее благодарю!

А какая разница в каких они директориях? Ты ж там image указываешь

Если указывать image, то, как я понимаю, при внесении изменений в один из сервисов нужно будет создавать docker-образ, заливать его в docker hub и в директории с docker-compose делать docker-compose pull <имя сервиса с image> Учитывая, что этот docker-compose.yml буду использовать для разработки, хотелось бы обойтись без этого (ну или добиться обновления файлов образа сервиса в реальном времени другим образом)

Вообще, возможно ли такое? И как обычно вы делаете?

Если указывать image, то, как я понимаю, при внесении изменений в один из сервисов нужно будет создавать docker-образ, заливать его в docker hub и в директории с docker-compose делать docker-compose pull <имя сервиса с image> Учитывая, что этот docker-compose.yml буду использовать для разработки, хотелось бы обойтись без этого (ну или добиться обновления файлов образа сервиса в реальном времени другим образом)

Ну компоуз на обычный ап сам новую версию скачает, а то что положить в registry надо - вполне нормальная практика

Хорошо, спасибо!

Если указывать image, то, как я понимаю, при внесении изменений в один из сервисов нужно будет создавать docker-образ, заливать его в docker hub и в директории с docker-compose делать docker-compose pull <имя сервиса с image> Учитывая, что этот docker-compose.yml буду использовать для разработки, хотелось бы обойтись без этого (ну или добиться обновления файлов образа сервиса в реальном времени другим образом)

почему бы не указывать? dockerfile в компоузе?

почему бы не указывать? dockerfile в компоузе?

А можно пример пожалуйста?

посмотрите директиву build

https://docs.docker.com/compose/compose-file/

https://docs.docker.com/compose/compose-file/compose-file-v2/

7,62

Калибр

Привет, не могли бы вы посоветовать легкие решения для сбора логов из экземпляров докеров Я вижу наиболее популярным решением является решение elasticsearch, Logstash, kibana https://elk-docker.readthedocs.io но, похоже, это требует выделенной виртуальной машины, поскольку он минимальные требования по памяти 3Гб. Вероятно, есть более простые решения чтоб взять логи приямо из docker std.out/err собрать их всех вместе, и предоставить простои web интерфейс для просмотра (хотя это и не обязательно)?

syslog, graylog

graylog — отличный способ. Logstash его использует. Формат открытый и крайне простой. Я написал небольшую программу, которая реализует logstash-сервер, и логи складываю так, как мне удобно с помощью 100Мб оперативной памяти, а не логсташевской монструозной джавы.

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

извини, ты откуда такой умный?))

извини, ты откуда такой умный?))

Извиняю) а что такое

>graylog — отличный способ спасибо посмотрю

graylog — отличный способ. Logstash его использует. Формат открытый и крайне простой. Я написал небольшую программу, которая реализует logstash-сервер, и логи складываю так, как мне удобно с помощью 100Мб оперативной памяти, а не логсташевской монструозной джавы.

зачемвам логстеш, если там нативный gelf?

gelf == graylog

о нем и речь

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

может есть ченидь типа общего хранилища кэшей?

чтобы несколько докер хостов могли его использовать

Есть Jenkins на win машине и docker на линуксовой , как лучше организовать сброку и деплой образа?

*сборку

чтобы несколько докер хостов могли его использовать

юзай докер хаб, или чегонить из опенсорса для хранения образов

юзай докер хаб, или чегонить из опенсорса для хранения образов

серьезно?

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

Делай свой хаб

серьезно?

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

Есть Jenkins на win машине и docker на линуксовой , как лучше организовать сброку и деплой образа?

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

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

👍 так и надо.

https://hub.docker.com/_/registry/ вот эту штуку юзаем для хранения образов, к ней еще ui есть

Так а как я на виндовой машине соберу новый образ и скажу докеру стартануть его?

в Digital Ocean ктонибудь докер хостит? У них есть готовый образы с докером но они под убунтой, убунта для докера это вообще норм? Просто у меня есть пару хостов с centos, там основной гемор для докера, что дефолтный фс бэкэнд для докера это луп девайсы, они медленные по понятным причинам, поэтому у меня под centos сделаны lvm разделы и юзается уже lvm как бэкэнд фс для докера. В DO несколько геморно получить тачку с lvm разделом, или может я просто слишком нуб, но как я понял если дроплет создал то уже ни как его основной раздел в lvm не конвернешь, только докупать как доп услугу еще раздел и его под lvm делать. А вот в убунте юзается aufs как бэкэнд докера, по дефолту, и там вроде как доп действий ни каких совершать не надо, следовательно на сколько это адекватное решение взять в DO готовый дроплет с убунутой+докер, вместо центос ? Кто не понял про что я говорю, я вот про это https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ и продакшен моде. Для кого то может быть открытием что нельзя докер юзать в том виде в котором он по дефолту ставится в Centos