Бог знает почему такая точка зрения торжествует в современной философии; по-моему, она просто вздорная. Человеку не жарко и не холодно от существования его копий, независимо от того, когда они начали или начнут существовать. Жонглирование информацией нисколько не отодвигает тьму, и плач, и скрежет зубовный.
В случае успеха жить будут «данные о моделях поведения, мыслительных процессах и особенностях функционирования организма». А ты, %username%, всё равно умрёшь.
Не реализовать гибкую подсистему сбора логов в готовом продукте − это некомпетентность проектировщика. Не представлять, в какой среде будет работать программа, как могут распределиться нагрузки − это некомпетентность проектировщика. Разработать эзотерическую систему деплоя и/или не задокументировать её − некомпетентность проектировщика. По всему выходит, что девопс − это такой козёл отпущения, заполняющий дыры в компетентности разработчиков, пока их не накопится критическая масса.
Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
Никогда не занимался никаким патченьем. Вот мой PyCharm: screencloud.net/v/qg0F. Работает субпиксельное сглаживание, как я понимаю. Оно мне никогда не мешало. Скажите, мои глаза уже вытекли или ещё нет?
Вот именно. Начинаешь с малого, постепенно организовываешь POSIX userspace в Windows, потом осознаёшь, что валяешь дурака, переходишь на Linux или MacOS и вздыхаешь с облегчением.
Я пытался примеряться к Windows как разработчик (Python), в том числе и как веб-разработчик (Django), и сделал вывод, противоположный вашему. На самом деле Windows не просто неудобна, а прямо-таки враждебна разработке.
Во-первых, в поставке системы нет компилятора.
Во-вторых, нет репозитория хотя бы для инструментов, я уж не говорю обо всём софте.
Оба фактора отстойны сами по себе, но в сочетании они просто убийственны. Сначала устанавливаешь CPython из одного места, pip − из другого. Потом выясняешь, что для использования pip тебе нужен Visual C++, причём именно версии 9. Торренты, файлопомойки, установка, битьё головой об стену, патч для vcvarsall.bat… Ах, да, C-расширения можно собрать только 32-битные, а ты уже установил 64-битный CPython! Перебираешь с полдюжины готовых сборок Python, в каждой из которых какая-нибудь мелочь тебе не нравится…
В общем, прощай, Windows, и снова здравствуй, Debian, в котором всё так скучно: “apt-get install” и “pip install”, дело сделано.
Административно − если на одном сервере несколько пользователей (команд) осуществляют развёртывание, то логичнее будет использовать для них отдельные места для хранения юнитов. Наверное.
В любом случае спасибо за статью, она заставила меня заинтересоваться systemd с немного неожиданной для меня точки зрения.
Я имею в виду, что ещё не разобрался до конца, как это сделать, но зато хорошо знаю, что я хочу. Смысл всей этой возни − запускать и перезапускать бэкенд-вебсервер и периодические задачи, обслуживающие сайт, от лица того же пользователя, который осуществляет деплоймент и тестирование. Это должен быть пользователь с минимальными привилегиями. Это ниша supervisor.
Как я понимаю, мне нужен не /lib/systemd/system/, а ~/.config/systemd/user/, и ещё “systemd --user” плюс нечто, называемое lingering. Именно это заменяет supervisord в его главном назначении: демонизировать пользовательские скрипты, отделяя их от пользовательской сессии.
Спасибо. Это действительно то, что нужно. systemd развивается так быстро, что за всеми фичами не уследишь. :) Я сейчас запускаю uwsgi, paster, celeryd, haystack на своём хостинге (Debian 8) при помощи supervisord. Пожалуй, стоит перенастроить это всё на systemd и сэкономить немного памяти.
Теперь попросим piromanlynx обновить соответствующим образом примеры в этой статье. Иначе заявленная тема не будет раскрыта. :)
Я ничего не имею против systemd, но, чтобы заменить supervisor, он должен обслуживать таски простых пользователей от их имени, не от root и без помощи sudo. Возможно ли такое?
Спутник, если говорить в терминах наземных ethernet-технологий − это пассивный концентратор. Он ничего не понимает в IP, не говоря уже о шифровании. Соответственно, подключившись к спутниковому каналу, можно и слушать всех соседей, и пакеты внедрять, как в старой общажной локалке на коаксиале.
Было такое понятие раньше: «спутниковая рыбалка», если кто ещё помнит. Самое безобидное, что можно со спутниковым трафиком делать.
Решение этой проблемы, если я вас правильно понял − создать собственный deb-репозиторий и добиться того, чтобы проект можно было развернуть только при помощи этого репозитория, без использования иных пакетных менеджеров, кроме apt?
Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в wheel. Он гарантированно развернётся. Правда, обновления безопасности для компонентов я не получу. Но это в любом случае требует разработчика. Просто wheel-репозиторий требует Python-разработчика, а переупаковка всего проекта или библиотек, которых нет в системном репо или которые в нём устарели, в deb-пакеты требует Python-разработчика, умеющего dpkg-buildpackage и прочую чорную магию. Либо выделить отдельную человекоединицу для упаковки пакетов, а этого далеко не всякий бюджет выдержит. Проще обойтись толковым пайтонистом кмк.
Правда, тут ниже мне уже советуют использовать Docker. Я так понимаю, что установив проект со всеми его сюрпризами в контейнер LXC, можно при помощи Docker сохранить снимок этого контейнера и деплоить проект из этого снимка. Я не знаю подводных камней этого процесса, но выглядит всяко проще, чем создавать deb-пакет на каждый чих.
Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
«Подъезжая к сией станцыи и глядя на природу в окно, у меня слетела шляпа.» (А. П. Чехов)
Во-первых, в поставке системы нет компилятора.
Во-вторых, нет репозитория хотя бы для инструментов, я уж не говорю обо всём софте.
Оба фактора отстойны сами по себе, но в сочетании они просто убийственны. Сначала устанавливаешь CPython из одного места, pip − из другого. Потом выясняешь, что для использования pip тебе нужен Visual C++, причём именно версии 9. Торренты, файлопомойки, установка, битьё головой об стену, патч для vcvarsall.bat… Ах, да, C-расширения можно собрать только 32-битные, а ты уже установил 64-битный CPython! Перебираешь с полдюжины готовых сборок Python, в каждой из которых какая-нибудь мелочь тебе не нравится…
В общем, прощай, Windows, и снова здравствуй, Debian, в котором всё так скучно: “apt-get install” и “pip install”, дело сделано.
Административно − если на одном сервере несколько пользователей (команд) осуществляют развёртывание, то логичнее будет использовать для них отдельные места для хранения юнитов. Наверное.
В любом случае спасибо за статью, она заставила меня заинтересоваться systemd с немного неожиданной для меня точки зрения.
Теперь попросим piromanlynx обновить соответствующим образом примеры в этой статье. Иначе заявленная тема не будет раскрыта. :)
Было такое понятие раньше: «спутниковая рыбалка», если кто ещё помнит. Самое безобидное, что можно со спутниковым трафиком делать.
Спасибо за наводку, не знал про эту штуку. Надо будет иметь в виду. Наверное, я изменю своё мнение насчёт сборки OS-targeted пакетов.
Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в wheel. Он гарантированно развернётся. Правда, обновления безопасности для компонентов я не получу. Но это в любом случае требует разработчика. Просто wheel-репозиторий требует Python-разработчика, а переупаковка всего проекта или библиотек, которых нет в системном репо или которые в нём устарели, в deb-пакеты требует Python-разработчика, умеющего dpkg-buildpackage и прочую чорную магию. Либо выделить отдельную человекоединицу для упаковки пакетов, а этого далеко не всякий бюджет выдержит. Проще обойтись толковым пайтонистом кмк.
Правда, тут ниже мне уже советуют использовать Docker. Я так понимаю, что установив проект со всеми его сюрпризами в контейнер LXC, можно при помощи Docker сохранить снимок этого контейнера и деплоить проект из этого снимка. Я не знаю подводных камней этого процесса, но выглядит всяко проще, чем создавать deb-пакет на каждый чих.
Мне показалось, или действительно пахнет дымом?