Size: a a a

Python — вакансии и аналитика

2020 April 02

VA

Vitality Androsenko in Python — вакансии и аналитика
Michael V
Ну чего ты сразу Сомали. Вот ездил в Камбоджу по работе в прошлом году. Хорошая страна, тепло, туктуки ездят, по вечерам народ в очередь за жареными тараканами выстраивается, РРР под 4000. На границе просят купить визу за 30 долларов. Карточкой нельзя, только либо местными непомнюужекаких, либо долларами. Ах у вас только евро? Тогда 35 евро. Человек в погонах на посту, вокруг с десяток еще людей в погонах плюс сотня "зрителей".
Ну. Тот же уровень. Не с тем равняешь.
источник
2020 April 03

R

Reid in Python — вакансии и аналитика
Michael V
Да в Украине вообще всё по-человечески практически с платежами. РФ уникальная в этом плане страна. Ну, среди цивилизованных.
Цивилизованных Россия ))))
источник

p

psy21d in Python — вакансии и аналитика
#вакансия #android

Мы небольшая команда энтузиастов

Сейчас один из наших проектов это VPN для андроид

Клиентское приложение уже на стадиии пре-релиза и сейчас нам нужна настройка серверов.

Это разворачивание новых серверов (ansible playbook) и их автоматизация на python

Эти сервера будут предназначены для доступа клиента на сервер

Мы составили краткий список самых важных вопросов
https://www.notion.so/vortexmr/d15bbe04f2824408bbbf9095606fd453

Зарплата 40000 рублей в месяц, работа удалённо

ЛС @psy21d
источник

yg

yu gu in Python — вакансии и аналитика
vasil
Докер-композ вообще удобная херь для разработки.
Главное postgres в него не пихать. Многим это не очевидно, как выяснилось :-)
источник

v

vvk in Python — вакансии и аналитика
yu gu
Главное postgres в него не пихать. Многим это не очевидно, как выяснилось :-)
А чо будет если запихнуть?
источник

v

vasil in Python — вакансии и аналитика
yu gu
Главное postgres в него не пихать. Многим это не очевидно, как выяснилось :-)
а в чем проблема? у меня запихнут туда и все работает ок
источник

IS

Ivan Sanin in Python — вакансии и аналитика
yu gu
Главное postgres в него не пихать. Многим это не очевидно, как выяснилось :-)
Во-первых, при чем тут композ, утилита для запуска. В нее физически ничего нельзя запихнуть) Во-вторых, заинтриговал и молчит. С какими проблемами столкнулся с postgres в контейнере? Интересно же)
источник

YC

Yury Chuker in Python — вакансии и аналитика
Ну я слышал мнение про то, что бд не особо класть в докер из-за проблем с бекапами (которые через volume можно решить), внешним доступом (которые тоже решаются нормальной настройкой того же композа)
источник

v

vvk in Python — вакансии и аналитика
Yury Chuker
Ну я слышал мнение про то, что бд не особо класть в докер из-за проблем с бекапами (которые через volume можно решить), внешним доступом (которые тоже решаются нормальной настройкой того же композа)
Все данные выносятся в volume-ы априори, это best practice
источник

IS

Ivan Sanin in Python — вакансии и аналитика
Конечно выносятся, они же иначе потеряются при перезапуске контейнера. Если база не для тестов, то скорее всего данные хочется сохранить))
источник

IS

Ivan Sanin in Python — вакансии и аналитика
Был сделан акцент на postgres, это подогревает особый интерес лично у меня
источник

v

vvk in Python — вакансии и аналитика
Ivan Sanin
Конечно выносятся, они же иначе потеряются при перезапуске контейнера. Если база не для тестов, то скорее всего данные хочется сохранить))
Ну не при перезапуске, а при пересоздании, если быть точным
источник

MB

Muslim Beibytuly in Python — вакансии и аналитика
Ivan Sanin
Во-первых, при чем тут композ, утилита для запуска. В нее физически ничего нельзя запихнуть) Во-вторых, заинтриговал и молчит. С какими проблемами столкнулся с postgres в контейнере? Интересно же)
Banned from the DBA
Docker is meant to be stateless. Containers have no permanent disk storage, whatever happens is ephemeral and is gone when the container stops. Containers are not meant to store data. Actually, they are meant by design to NOT store data. Any attempt to go against this philosophy is bound to disaster.
Moreover. Docker is locking away processes and files through its abstraction, they are unreachable as if they didn’t exist. It prevents from doing any sort of recovery if something goes wrong.
Long story short. Docker SHALL NOT run databases in production, by design.
It gets worse than that. Remember the ongoing kernel panics with docker?
A crash would destroy the database and affect all systems connecting to it. It is an erratic bug, triggered more frequently under intensive usage. A database is the ultimate IO intensive load, that’s a guaranteed kernel panic. Plus, there is another bug that can corrupt the docker mount (destroying all data) and possibly the system filesystem as well (if they’re on the same disk).
Nightmare scenario: The host is crashed and the disk gets corrupted, destroying the host system and all data in the process.
Conclusion: Docker MUST NOT run any databases in production, EVER.
Every once in a while, someone will come and ask “why don’t we put these databases into docker?” and we’ll tell some of our numerous war stories, so far, no-one asked twice.
источник

YC

Yury Chuker in Python — вакансии и аналитика
Это откуда?
источник

IS

Ivan Sanin in Python — вакансии и аналитика
Yury Chuker
Это откуда?
Вероятно, отсюда
источник

MB

Muslim Beibytuly in Python — вакансии и аналитика
Yury Chuker
Это откуда?
Старая статья, часть давно скопировал из-за частых вопросов в команде насчёт «почему мы не засунем вообще все в контейнеры?»
источник

IS

Ivan Sanin in Python — вакансии и аналитика
Muslim Beibytuly
Banned from the DBA
Docker is meant to be stateless. Containers have no permanent disk storage, whatever happens is ephemeral and is gone when the container stops. Containers are not meant to store data. Actually, they are meant by design to NOT store data. Any attempt to go against this philosophy is bound to disaster.
Moreover. Docker is locking away processes and files through its abstraction, they are unreachable as if they didn’t exist. It prevents from doing any sort of recovery if something goes wrong.
Long story short. Docker SHALL NOT run databases in production, by design.
It gets worse than that. Remember the ongoing kernel panics with docker?
A crash would destroy the database and affect all systems connecting to it. It is an erratic bug, triggered more frequently under intensive usage. A database is the ultimate IO intensive load, that’s a guaranteed kernel panic. Plus, there is another bug that can corrupt the docker mount (destroying all data) and possibly the system filesystem as well (if they’re on the same disk).
Nightmare scenario: The host is crashed and the disk gets corrupted, destroying the host system and all data in the process.
Conclusion: Docker MUST NOT run any databases in production, EVER.
Every once in a while, someone will come and ask “why don’t we put these databases into docker?” and we’ll tell some of our numerous war stories, so far, no-one asked twice.
Я бы сказал, зависит от задачи. Кейс "запуск в проде" - один из возможных кейсов. Вот менее кричащее мнение. Опять же в комментариях статьи 2016-го года есть адепты разных точек зрения даже на вопрос прода.

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

MB

Muslim Beibytuly in Python — вакансии и аналитика
Ivan Sanin
Я бы сказал, зависит от задачи. Кейс "запуск в проде" - один из возможных кейсов. Вот менее кричащее мнение. Опять же в комментариях статьи 2016-го года есть адепты разных точек зрения даже на вопрос прода.

А вообще круто было бы услышать истории из жизни факапов базы в контейнере от здесь присутствующих. Что нам гугл
Знаю точно что у соседнего проекта некритичный сервис с бд в контейнере упал, volume оказался недоступен для работы. Перенесли на replicaset k8s, devops побили всех по рукам и больше инцидентов не возникало. Все ещё в разработке запускаем кучу контейнеров бд в тестовой среде
источник

IS

Ivan Sanin in Python — вакансии и аналитика
vvk
Ну не при перезапуске, а при пересоздании, если быть точным
Верное замечание
источник

v

vvk in Python — вакансии и аналитика
Muslim Beibytuly
Banned from the DBA
Docker is meant to be stateless. Containers have no permanent disk storage, whatever happens is ephemeral and is gone when the container stops. Containers are not meant to store data. Actually, they are meant by design to NOT store data. Any attempt to go against this philosophy is bound to disaster.
Moreover. Docker is locking away processes and files through its abstraction, they are unreachable as if they didn’t exist. It prevents from doing any sort of recovery if something goes wrong.
Long story short. Docker SHALL NOT run databases in production, by design.
It gets worse than that. Remember the ongoing kernel panics with docker?
A crash would destroy the database and affect all systems connecting to it. It is an erratic bug, triggered more frequently under intensive usage. A database is the ultimate IO intensive load, that’s a guaranteed kernel panic. Plus, there is another bug that can corrupt the docker mount (destroying all data) and possibly the system filesystem as well (if they’re on the same disk).
Nightmare scenario: The host is crashed and the disk gets corrupted, destroying the host system and all data in the process.
Conclusion: Docker MUST NOT run any databases in production, EVER.
Every once in a while, someone will come and ask “why don’t we put these databases into docker?” and we’ll tell some of our numerous war stories, so far, no-one asked twice.
Всё верно, данные БД нельзя пихать в контейнер, а так разницы нет, работает с базой на диске процесс постгреса из докера или из хост-системы
источник