Проблемы с локальной разработкой и развертыванием Wordpress

Настройка:

Я настраиваю приложение на базе Wordpress, используя Elastic Beanstalk от Amazon Web Services. Вся разработка выполняется локально в среде сервера MAMP apache2/php5 с репозиторием GIT, контролирующим весь корень приложения.

Рабочий процесс развертывания:

После внесения в репозиторий любых изменений кода (правок, новых плагинов и т. д.) приложение развертывается с помощью команды eb deploy интерфейса командной строки AWS EB, которая отправляет последнюю версию во все работающие экземпляры EC2, управляемые Elastic Beanstalk.

Моя проблема:

Иногда изменения кода не совсем синхронизируются между моими средами разработки/производства, и я не знаю, как это преодолеть. Особенно при попытке установить и настроить такие плагины, как W3 Total Cache или WP Super Cache.

Поскольку в моей локальной среде не установлены такие вещи, как сервер memcahced, но в моей производственной среде он есть (ElastiCache), я не могу сохранить правильный файл настроек и развернуть его для использования в своей производственной среде. Эти плагины не позволяют мне выбрать нужные службы, потому что видят их недоступными...

Кажется, я могу заставить W3 Total Cache работать только в том случае, если я установлю его непосредственно в рабочую среду, что кажется плохой идеей.

Учитывая вышеизложенное:

  • Я неправильно подхожу к развертыванию?

  • Следует ли устанавливать и настраивать такие подключаемые модули, как W3 Total Cache, в локальных средах разработки и переносить в рабочие среды?


deployment amazon-web-services wordpress amazon-elastic-beanstalk w3-total-cache
person Rich    schedule 02.02.2015    source источник
comment
в чем именно тут вопрос? что не работает?   -  person Tal    schedule 02.02.2015
comment
@tal Я просто выделил вопросы для большей ясности.   -  person Rich    schedule 03.02.2015

Ответы (2)


arrow_upward
2
arrow_downward

Я не могу комментировать проблемы, характерные для Elastic Beanstalk, но, основываясь на опыте, могу сделать предложение по второй части вашего заявления о проблеме:

Вам лучше использовать среду разработки, которая максимально точно отражает вашу производственную среду. Я предлагаю вам перейти из MAMP в среду VM, такую ​​​​как VirtualBox. Возможно, вы захотите посетить puppet.com, чтобы получить помощь в его настройке. Это требует некоторых усилий при запуске, но дает вам среду, подобную или такую ​​же, как ваши рабочие серверы. Например, вы можете запустить memcached самостоятельно, чтобы проверить его с помощью W3 Total Cache.

Что касается вашего второго вопроса, то просто установка плагина в производственной среде без его предварительного тестирования сопряжена с очевидными рисками (но опять же, клиенты делают это постоянно). Я бы предпочел сначала проверить. В определенной степени это, вероятно, зависит от того, насколько критично, если сайт испытывает простои или странности.

person Community    schedule 02.02.2015
comment
Спасибо за помощь. На самом деле я наткнулся на Vagrant как на альтернативу MAMP и вчера начал с ним играться. Похоже, потребуется некоторая работа, чтобы заставить среду разработки соответствовать тому, что раскручивает AWS Elastic Beanstalk, но вы правы, виртуальная машина — это путь. - person Rich; 03.02.2015
comment
Да, Vagrant очень полезен. Я все же рекомендую вам взглянуть на phppet. По сути, это интерфейс для Vagrant. Он позволяет вам выбрать несколько параметров, а затем создает файлы конфигурации Vagrant, чтобы vagrant up делал то, что вы хотите. Я считаю, что Beanstalk управляется даже марионеткой. - person ; 03.02.2015

arrow_upward
1
arrow_downward

Я бы посоветовал вам создать еще одну среду на Beanstalk. В вашем случае это просто, быстро и надежнее, чем виртуальная машина, потому что вы также сможете протестировать процесс развертывания.

У меня обычно есть 3 среды для каждого сайта. Каждая среда находится в своей ветке. Если ваша конфигурация отличается в зависимости от среды (например, URL-адрес и доступ к базе данных), просто сохраните ваш wp-config и другие файлы конфигурации в S3 (возможно, вам не нужен производственный пароль в вашем репозитории git), и через ebextensions вы можете загрузить их в свой сайт автоматически.

Таким образом я использую AWS Beanstalk для 16 веб-сайтов, а некоторые из них — WordPress. Все с автомасштабированием и возможностью одновременного подключения тысяч пользователей.

Не стесняйтесь спрашивать меня о дальнейших подробностях.

person Eric D.    schedule 03.02.2015