Бэкапы делать хорошо, хранить их не на том же сервере ещё лучше. Ведь если с сервером что-то случится и он будет не доступен, то и бэкапы тоже окажутся в недосягаемости. И то что они делались, не будет большим утешением.
Что-нибудь делали чтобы не терять сообщения, если их количество превышает лимиты телеграма? В пуллинг модели можно обойтись готовой очередью из telegram-bot-api, а с вебхуками и несколькими инстансами бота та очередь уже не поможет
Почему так хейтят выш мат? Не понимаю. Сами по себе знания может и не пригодятся в явном виде. НО предмет сильно прокачивает умение мыслить аналитически. А это, имхо, сильно важнее, чем практический опыт работы с модным сегодня фреймворком на хайповом языке. Последние при хорошей базе осваиваются самостоятельно за пару недель на достаточно высоком уровне для того чтобы задвинуть ребят даже из идеального ПТУ.
Если код только на Go и не дёргается либ на С, то всё что нужно для кросскомпиляции — это Go SDK.
Тут Go на несколько порядков удобнее других языков. Не нужно тащить ни библиотек, ни виртуальных машин, ни интерпретаторов.
А ведь у некоторых нет ни ролей, ни разделения прав доступа и все заходят на сервер под одной учёткой с рутовым доступом с паролем записанным на листок бумаги и пароль этот никогда не меняется.
Мне всегда казалось, что сложную бизнес логику пишут на Java или C#. Тогда как Python больше про скорость разработки для стартапов и науки. Мимо этого заблуждения ещё можно пройти.
Но записать Go в скриптовые языки (да даже в статье упоминаются статическая типизация и компиляция)! Это на грани добра и зла.
Когда-то на заре знакомства с Docker чёрт дёрнул сделать так же (собирать образы на той же машине, на которой они затем запускаются). Вот очень похоже было на вашу возню с артефактами.
И плохо в таком подходе практически всё. Начиная с того что использование продакшн сервера для каких-либо билдов сама по себе идея странная. И заканчивая тем, что весь этот процесс не слишком то легко повторять для разных стеков технологий.
Если не делать 'FROM: ubuntu:latest', а открыть для себя alpine образы, то в итоге образ и будет тем самым артефактом в котором нет ничего кроме приложения с минимально необходимыми для него зависимостями. Да, так нельзя запустить наше приложение на машине без докера, но фокус в том, что вне докера у приложения есть другие зависимости от самых разных библиотек и их установка может быть в разы сложнее установки докера. А если вдруг мы писали на маке, тестировщик тестит на винде, а на проде линукс, то…
Позже открыл для себя системы оркестрации (сначала Docker Swarm, сейчас Kubernetes) и managed databases, выбросил ansible. Конфигов стало меньше, реюзабельность стала выше (в CI/CD для Python и Go, например, отличается один только Dockerfile).
Возможность использовать разные версии софта (передаю привет php.ini) скорее приятный бонус, чем основная фича контейнеров. Они позволяют решать куда более широкий круг задач и в разработке, и в тестировании, и в оперировании. А после первого опыта с системами оркестрации, мало у кого возникнет желание деплоить приложение в прод "по-старому".
Таки не хостовую ОС, а ядро и не любое, а Linux. Я для себя какое-то очень базовое представление имею, как оно устроено. Но было бы здорово, иметь хорошо изложенное описание работы контейнеров, чтобы и самому понимание подкрепить и другу ссылку сбросить.
Практически все сравнивают контейнеры с виртуальными машинами, делают акцент на том что контейнеры требуют меньше ресурсов, но мало кто объясняет почему. Вот об этом было бы интереснее прочесть, чем про сравнение Docker и пиццы.
Так Docker как раз и решает проблему разницы между продом и дев окружением. И не только эту. Но взамен требует изменить подход к разработке достаточно сильно, что судя по всему часто вызывает непонимание того, зачем вообще он нужен разработчикам, если и без него всё работает.
Описанное в статье как раз и годиться только для машины разработчика или тестировщика. Тащить это на сервер (любой) плохая идея и не только из-за возможных проблем с безопасностью. Описаное в принципе не является хорошим примером работы с контейнерами.
docker run --restart=always ...
После перезапуска всё продолжит работать. Не то чтобы это best practices, но docker daemon может стартовать контейнеры автоматически.
так ведь и база данных тоже расти будет
Бэкапы делать хорошо, хранить их не на том же сервере ещё лучше. Ведь если с сервером что-то случится и он будет не доступен, то и бэкапы тоже окажутся в недосягаемости. И то что они делались, не будет большим утешением.
Диск тоже не резиновый и место может закончиться.
В github есть deploy keys, с read only доступом.
Для тех кто не собирается изменять код прямо на сервере.
Не совсем то. Я о исходящих сообщениях. В случае превышения лимитов на сервер телеграма они не попадут, нужно делать свою очередь
Что-нибудь делали чтобы не терять сообщения, если их количество превышает лимиты телеграма? В пуллинг модели можно обойтись готовой очередью из telegram-bot-api, а с вебхуками и несколькими инстансами бота та очередь уже не поможет
Для отправки сообщений не нужны ни пуллинг, ни вебхуки. Достаточно requests и знаний об api
Почему так хейтят выш мат? Не понимаю. Сами по себе знания может и не пригодятся в явном виде. НО предмет сильно прокачивает умение мыслить аналитически. А это, имхо, сильно важнее, чем практический опыт работы с модным сегодня фреймворком на хайповом языке. Последние при хорошей базе осваиваются самостоятельно за пару недель на достаточно высоком уровне для того чтобы задвинуть ребят даже из идеального ПТУ.
Если код только на Go и не дёргается либ на С, то всё что нужно для кросскомпиляции — это Go SDK.
Тут Go на несколько порядков удобнее других языков. Не нужно тащить ни библиотек, ни виртуальных машин, ни интерпретаторов.
После первых анонсов была надежда на Docker без виртуальной машины. Но нет, ВМ на месте.
А заработает ли Docker с WSL 2? И если да, то это решение будет лучше или хуже того, что сейчас предлагается для Windows?
А ведь у некоторых нет ни ролей, ни разделения прав доступа и все заходят на сервер под одной учёткой с рутовым доступом с паролем записанным на листок бумаги и пароль этот никогда не меняется.
Сюжет из ночного кошмара безопасников.
Мне всегда казалось, что сложную бизнес логику пишут на Java или C#. Тогда как Python больше про скорость разработки для стартапов и науки. Мимо этого заблуждения ещё можно пройти.
Но записать Go в скриптовые языки (да даже в статье упоминаются статическая типизация и компиляция)! Это на грани добра и зла.
И плохо в таком подходе практически всё. Начиная с того что использование продакшн сервера для каких-либо билдов сама по себе идея странная. И заканчивая тем, что весь этот процесс не слишком то легко повторять для разных стеков технологий.
Если не делать 'FROM: ubuntu:latest', а открыть для себя alpine образы, то в итоге образ и будет тем самым артефактом в котором нет ничего кроме приложения с минимально необходимыми для него зависимостями. Да, так нельзя запустить наше приложение на машине без докера, но фокус в том, что вне докера у приложения есть другие зависимости от самых разных библиотек и их установка может быть в разы сложнее установки докера. А если вдруг мы писали на маке, тестировщик тестит на винде, а на проде линукс, то…
Позже открыл для себя системы оркестрации (сначала Docker Swarm, сейчас Kubernetes) и managed databases, выбросил ansible. Конфигов стало меньше, реюзабельность стала выше (в CI/CD для Python и Go, например, отличается один только Dockerfile).
Спасибо, полезно.
Можно конечно пойти немного более простым путём и поручить эту работу ansible.
Контейнер это не полноценная система,. Хостом может быть только Linux, а на Windows и Mac Docker работает в виртуальной машине.
Возможность использовать разные версии софта (передаю привет php.ini) скорее приятный бонус, чем основная фича контейнеров. Они позволяют решать куда более широкий круг задач и в разработке, и в тестировании, и в оперировании. А после первого опыта с системами оркестрации, мало у кого возникнет желание деплоить приложение в прод "по-старому".
Таки не хостовую ОС, а ядро и не любое, а Linux. Я для себя какое-то очень базовое представление имею, как оно устроено. Но было бы здорово, иметь хорошо изложенное описание работы контейнеров, чтобы и самому понимание подкрепить и другу ссылку сбросить.
Практически все сравнивают контейнеры с виртуальными машинами, делают акцент на том что контейнеры требуют меньше ресурсов, но мало кто объясняет почему. Вот об этом было бы интереснее прочесть, чем про сравнение Docker и пиццы.
Так Docker как раз и решает проблему разницы между продом и дев окружением. И не только эту. Но взамен требует изменить подход к разработке достаточно сильно, что судя по всему часто вызывает непонимание того, зачем вообще он нужен разработчикам, если и без него всё работает.
Описанное в статье как раз и годиться только для машины разработчика или тестировщика. Тащить это на сервер (любой) плохая идея и не только из-за возможных проблем с безопасностью. Описаное в принципе не является хорошим примером работы с контейнерами.
docker run --restart=always ...После перезапуска всё продолжит работать. Не то чтобы это best practices, но docker daemon может стартовать контейнеры автоматически.