но старая

но сильно лучше не стало

но стало :)

Да бредовая эта статья. И к тому же старая.

от июля то старая? )

Может я путаю. Ту где чувак патчил ядро и у паники сыпались

и я знаю, что это перевод от 16 года )

Ядро 3.16

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

В статье

Ядро 3.16

а вы видели продакш ядро выше 3.10?

срач here there everywhere

а вы видели продакш ядро выше 3.10?

Видел)

Видел)

только не говорите мне пожалуйста про 4.4 )

Не про ядра разговор, а про актуальность статьи

Но да, 4.4 тоже есть

=)

и даже 4.8

Не про ядра разговор, а про актуальность статьи

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

и даже 4.8

это не прод

раз уж его дают для 16.04 lts

stable != production

Такого понятия как production нет в наименовании ядра

Такого понятия как production нет в наименовании ядра

да ну!?

ну я спокойно linux-generic-hwe-16.04 ставлю, и ничего никогда мне за это не было

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

все остальные либо лижут, либо слизывают.

это даже правда, наверное. но дистрибутив-то говно (мамонта)

понятно, что если даже сейчас рассматривать их ядро 3.10 там очень много кода из 4, но оно работает.

поэтому приходится расчитывать на то, что убунтовцы все важное бекпортят

федорка посвежей будет ))

или форвардпортят

и тоже редхат

федорка посвежей будет ))

федора это тестовый стенд редхата )

федорка посвежей будет ))

в прод?! никогда

для отчаянно смелых ))

для вазелиновых ))

под редхат здесь имелся в виду редхат или центось?

под редхат здесь имелся в виду редхат или центось?

это одно и тоже

centos тоже теперь уже под крылом redhat'а

она всегда там была как и федора

Red Hat Enterprise Linux

обычно это называют редхатом ))

она всегда там была как и федора

не всегда

ну зато он не древний как говно мамонта

ну зато он не древний как говно мамонта

это вам так кажется ;)

и очень даже стейбл

дебиан наверно не особо то свежей будет

это вы тут точно про голанг разговариваете?

офтопим

это вы тут точно про голанг разговариваете?

плааааавно перешли ))

Go -> Docker -> Kernel -> Linux Distributions

Логичная же цепочка)

скоро на железо перейдем ))

электроны говно

фотоны рулят

*ну чтобы сразу пару уровней перепрыгнуть

электроны твои полем отклоняются

и у них заряд

упс

надо же за них топить, а не ругать

Товарищи, подскажите простой способ мониторить файловую систему (пару директорий) на Go, в какую сторону посмотреть

Товарищи, подскажите простой способ мониторить файловую систему (пару директорий) на Go, в какую сторону посмотреть

github.com/fsnotify/fsnotify

Товарищи, подскажите простой способ мониторить файловую систему (пару директорий) на Go, в какую сторону посмотреть

https://ru.wikipedia.org/wiki/Inotify#.D0.A3.D1.82.D0.B8.D0.BB.D0.B8.D1.82.D1.8B

https://ru.wikipedia.org/wiki/Inotify#.D0.A3.D1.82.D0.B8.D0.BB.D0.B8.D1.82.D1.8B

на винде не заработает, как я понимаю?

"Inotify — это подсистема ядра Linux"

ERROR: S client not available

А вот выше через библиотек заработает

Спасибо

а ради интереса, чем адаптеры отличаются inotify от fanotify?

1 процесс - 1 контейнер

это не конкретное требование, а рекомендация не лепить в контейнер все подряд. Есть миллион образов вида а+б, например node+ruby и они вполне юзаются Each container should have only one concern Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. For instance, a web application stack might consist of three separate containers, each with its own unique image, to manage the web application, database, and an in-memory cache in a decoupled manner. You may have heard that there should be “one process per container”. While this mantra has good intentions, it is not necessarily true that there should be only one operating system process per container. In addition to the fact that containers can now be spawned with an init process, some programs might spawn additional processes of their own accord. For instance, Celery can spawn multiple worker processes, or Apache might create a process per request. While “one process per container” is frequently a good rule of thumb, it is not a hard and fast rule. Use your best judgment to keep containers as clean and modular as possible. If containers depend on each other, you can use Docker container networks to ensure that these containers can communicate. https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/

Нубский вопрос, но подскажите пожалуйста. Создаю docker image с помощью Dockerfile. Указал FROM golang 1.9 stretch, все работает. А nginx использовать или как? Если я например статику хочу отдавать. Как nginx в dockerfile указывать? И вообще нужно?

го умеет вебсервер - зачем нужен nginx?

го умеет вебсервер - зачем нужен nginx?

Статику отдавать

Round robin на upstream

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

го умеет вебсервер - зачем нужен nginx?

ssl терминировать еще

LB

ssl терминировать еще

Это и без nginx можно Другой момент что это удобно

1 процесс - 1 контейнер

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

Подскажите пожалуйста. Используют Dokerfile. FROM golang:onbuild Какая должна быть структура проекта?

Нигде не могу найти пример.

никакая специальная

А dependencies он сам скачает?

Кто скачает? Dependencies к чему?

Системы, Go?

Которые прописаны в .go

Возможно меня поправят, но скачивать зависимости в контейнере для Go - не очень хорошая затея.

А как?

У меня файл билдится внутри

В чем цель вообще использования докера в данном случае? Для выкатки или специфической сборки бинарника?

Всё, заработало )

В чем цель вообще использования докера в данном случае? Для выкатки или специфической сборки бинарника?

Балуюсь.

Ковыряюсь с Elastic Beanstalk

Да, прошу прощения, не посмотрел образ golang:onbuild. Все сам скачает.

Да, прошу прощения, не посмотрел образ golang:onbuild. Все сам скачает.

Тебе спасибо. Я прочитал где-то, что нужна строгая структура проекта. Оказывается нет..

Он просто берет main() из package main?

Нет, там немного сложней

This script allows us to take a generic directory of Go source files such as "/go/src/app" and determine that the canonical "import path" of where that code expects to live and reference itself is "github.com/jsmith/my-cool-app". It will then ensure that "/go/src/github.com/jsmith/my-cool-app" is a symlink to "/go/src/app", which allows us to build and run it under the proper package name.