Устанавливать дополнительную утилиту, которая будет постоянно синхронизировать изменения в фоновом режиме… Явно ненужное усложнение. Шара и так прекрасно монтируется и устойчиво работает, как будто на сервере разработки локальный диск. Тут нет проблем с сетевым соединением, т.к. все происходит на одном и том же компьютере. Сервер samba ставить не нужно, в качестве сервера выступает Windows-машина. На сервере разработки нужен только mount.cifs, который может даже устанавливать не надо (не помню, кажется, входит в стандартный дистрибутив CentOS).
Я считаю, что все зависит от ситуации. Да, вы правы, решения с vagrant и docker безусловно лучше собственного велосипеда и мы на них перейдем. Это уже шаг в сторону масштабирования. Когда будет разрастаться команда, усложнятся конфигурации и будут разными для разных проектов. Пока мы реально не испытывали в этом необоходимости, т.к. состав команды постоянный, нас немного, конфигурация виртуалки примерно одна и та же для всех проектов. Вполне достаточно дать новому разработчку скопировать виртуалку и после несложных настроек он в строю.
Выше предложили использовать динамические виртуальные хосты, может это самое правильное.
Перезаписываю, т.к. у нас не требуется каких-то особых настроек, веб-сокеты в проектах не используются. Какие-то мелкие настройки внести через .htaccess. Зато не остается мусора, если папку с проектом убрали или переименовали.
Да, динамические хосты похоже тут будут лучше — хорошее замечание. Не уверен, можно ли в динамических хостах делать специфические настройки под разные папки, но думаю, это решаемо…
Я думал на тему удаленного сервера. Не нравится, что все разработчики будут зависеть от его функционирования. Мне ближе идеология git, когда у каждого разработчика своя независимая инфраструктура для разработки.
Не совсем понял, для чего вы привели ansible. Речь в статье вроде бы совершенно не об этом. А о том, как построить окружение на локальном компьютере разработчика.
Проекты в production у нас работают или на одном сервере, или если серверов несколько, в Amazon Beanstalk, который берет управление развертыванием на себя.
Да, с дизайном я, что называется, не мудрствовал лукаво. Например, библиотека Машкова (lib.ru) стала очень популярна, а там дизайна ну совсем не было. Но многие пишут, что отсутствие дизайна отпугивает, так что повод задуматься конечно…
Другие пользователи, возможно, поймут, что здесь что-то не так и понизят рейтинг. Ну и в конечном счете вы же обманываете сами себя, а какой в этом смысл. Этот сайт, как клуб анонимных алкоголиков:), для тех, кто понял, что с ленью надо бороться и хочет, чтобы ему помогли.
Но тогда будет другая проблема — убрать эту опцию, когда slave начинает обслуживать пользователей? Придется писать скрипт, который будет редактировать my.cnf и перезапускать mysql?
Я делал это год назад, а убунту 8.04.4 вышла в январе 2010, не такая уже древняя на мой взгляд.
Насчет 100$ фрилансеру… Мне это не кажется хорошим решением. Я больше доверяю специалистам 1С-Битрикс (не сочтите за рекламу). Они делают качественно настроенную виртуалку с LAMP.
Вариант с размещением на внешнем хостинге рассматривал. Но там есть минусы: зависимость от Интернета, сложности с монтированием файлового сервера к виртуалке с порталом и вообще с интеграцией в инфраструктуру локальной сети предприятия. Вариант с размещением серверов внутри показался предпочтительнее. Но я не исключаю, что в следующих проектах попробую вариант с внешним хостингом портала (он, безусловно, имеет и свои плюсы).
Если можно поподробнее. Разве не получится, что если я переведу slave в режим read-only, он перестанет у себя выполнять запросы на изменения, приходящие с master и репликация не будет происходить?
Я же на slave имею 2 пользователя MySQL — под одним идет репликация, под другим работают скрипты портала. И я запрещаю изменения тому пользователю, под которым работают скрипты портала, до того момента, пока не прервется репликация и slave не начнет обслуживать пользователей.
На файловом сервере помимо файлов портала хранятся и другие файлы. Там делается регулярный бекап, а может он даже на RAID-массиве, это уже не входит в мою компетенцию в этой организации.
Надежность системы в целом повышается благодаря децентрализации ее частей.
С этим я согласен, но просто реалии таковы, что поднимать полноценный кластер с DRBD, Heartbeat уже не укладывалось в бюджет проекта. У меня самого на изучение ушло бы много времени и сил, меня хватило на то, на что хватило. А нанимать админа для создания кластера уже не входило в бюджет ну никак.
Но я все равно пробовал найти людей, умеющих делать кластеры DRBD, Heartbeat на сайтах фриланса. Почему-то все говорили, что опыта такого нет. Даже до обсуждения вознаграждения не доходило.
Убунта не такая уж древняя, она выпущена 28 января 2010 года, а я собирал эту систему год назад. Сейчас уже, конечно, есть более новые версии.
А виртуалка — удобная вещь. Ее можно легко копировать, запоминать состояния и откатывать в случае проблем. Можно в случае чего запускать на любом компьютере и под разными операционными системами.
Это происходит если войти в портал на slave, в его базу производится, например, запрос INSERT. Соответственно при этом для вставляемой записи в таблице генерится новый ID. При этом на master запускается другой INSERT. И когда в дальнейшем с master приходит этот запрос уже по каналу репликации, то оказывается, что у slave уже есть запись с таким ID и это приводит к разрыву репликации.
По замыслу это делается вручную так:
1) восстанавливается виртуалка master (или откатываю на предыдущий safe-state или беру просто исходную)
2) актуализирую ее (разворачиваю последний дамп базы, взятый со slave, заливаю последние версии скриптов)
3) включаю master в сеть, slave соответственно отключается от сети, подключаю обратно кабель репликации
slave с master местами никогда не меняю. У них есть ряд специфических настроек, они не вполне взаимозаменяемые. Slave нужен, чтобы временно взять работу на себя, чтобы можно было спокойно восстановить master и вернуть все на круги своя.
Да, это восстановление довольно трудоемое (ну 1-2 часа, максимум занимает), но и виртуалка падает крайне редко (стучу по дереву). На самом деле из моего опыта в двух организациях, такая виртуалка, работающая внутри сети годами не дает никаких сбоев.
Перезаписываю, т.к. у нас не требуется каких-то особых настроек, веб-сокеты в проектах не используются. Какие-то мелкие настройки внести через .htaccess. Зато не остается мусора, если папку с проектом убрали или переименовали.
Проекты в production у нас работают или на одном сервере, или если серверов несколько, в Amazon Beanstalk, который берет управление развертыванием на себя.
В другой фирме у меня аналогичная виртуалка работает уже много лет (года 3, как минимум) без сбоев…
Но тогда будет другая проблема — убрать эту опцию, когда slave начинает обслуживать пользователей? Придется писать скрипт, который будет редактировать my.cnf и перезапускать mysql?
Насчет 100$ фрилансеру… Мне это не кажется хорошим решением. Я больше доверяю специалистам 1С-Битрикс (не сочтите за рекламу). Они делают качественно настроенную виртуалку с LAMP.
Вариант с размещением на внешнем хостинге рассматривал. Но там есть минусы: зависимость от Интернета, сложности с монтированием файлового сервера к виртуалке с порталом и вообще с интеграцией в инфраструктуру локальной сети предприятия. Вариант с размещением серверов внутри показался предпочтительнее. Но я не исключаю, что в следующих проектах попробую вариант с внешним хостингом портала (он, безусловно, имеет и свои плюсы).
Я же на slave имею 2 пользователя MySQL — под одним идет репликация, под другим работают скрипты портала. И я запрещаю изменения тому пользователю, под которым работают скрипты портала, до того момента, пока не прервется репликация и slave не начнет обслуживать пользователей.
Надежность системы в целом повышается благодаря децентрализации ее частей.
Но я все равно пробовал найти людей, умеющих делать кластеры DRBD, Heartbeat на сайтах фриланса. Почему-то все говорили, что опыта такого нет. Даже до обсуждения вознаграждения не доходило.
А виртуалка — удобная вещь. Ее можно легко копировать, запоминать состояния и откатывать в случае проблем. Можно в случае чего запускать на любом компьютере и под разными операционными системами.
1) восстанавливается виртуалка master (или откатываю на предыдущий safe-state или беру просто исходную)
2) актуализирую ее (разворачиваю последний дамп базы, взятый со slave, заливаю последние версии скриптов)
3) включаю master в сеть, slave соответственно отключается от сети, подключаю обратно кабель репликации
slave с master местами никогда не меняю. У них есть ряд специфических настроек, они не вполне взаимозаменяемые. Slave нужен, чтобы временно взять работу на себя, чтобы можно было спокойно восстановить master и вернуть все на круги своя.
Да, это восстановление довольно трудоемое (ну 1-2 часа, максимум занимает), но и виртуалка падает крайне редко (стучу по дереву). На самом деле из моего опыта в двух организациях, такая виртуалка, работающая внутри сети годами не дает никаких сбоев.