Обновить
1
0
Денис Чепиль@chepil

Пользователь

Отправить сообщение
в документации к apex описано несколько сервисов, включая glassfish, лоджик… етц…
но там нет tomcat и прочей java лабудени. потому, что люди, которые ставят оракл в связке с апекс на продакшн, знают что делают, и им не нужно полу решение. Они не хотят nginx, они хотят сразу готовое решение, такое, как например weblogic. Но я не спец, и сильно могу ошибаться.
Конечно, я не умаляю достоинство nginx и tomcat, но как говорил великий классик, weblogic это мерседес в мире презервативов. самое мощное решение. как писали ниже, пушка для воробьев… но это все конечно не более, чем мое мнение, могу ошибаться
Мой личный опыт, говорит, что я, дурак такой, так и не смог заставить 4 glassfish полноценно работать с apex, без глюков. Оно как бы работает, но как бы глючит в плане админки. Можно конечно его ручками заставить и через консоль все делать. Тогда, оно, как бы работает. Но есть метод администрирования — ленивое администрирование. Это когда пишем в web браузере хытытыпыэс://адрес консоли. Оно открывается, но глючит и не работает как нужно, потому что я дурак, руки кривые, окружение не правильное, и президент конечно виноват. американский… В общем, насколько 3ка хорошо работает, настолько 4ка глючная, кроме того, оракл как бы сам официально не поддерживал 4ку в связке для apex. У меня сведения могут устареть, так как с 4кой я мучился пол года назад, а сейчас живу на weblogic…
Когда люди говорят — Oracle, то они либо покупают его, и нужна полная и полноценная обвязка, включая все, для чего вообще оракл нужен, либо, люди нагло, откровенно и по советски, воруют у буржуинов. И в первом, и во втором случае, вопрос цены не стоит. Либо есть бабло на все, включая блекджек и шлюх, либо, люди воруют принципиально, чтобы буржуины хуже жили, а блек джек и шлюхи — образ жизни. В обоих случаях, не нам, нищебродам, рассуждать о том, какое решение лучше с точки зрения цены. Вопрос цены вообще не нужно рассматривать. Деньги зло.
Я категорически против apache и/или nginx
Если уж писать статью, о том, как разворачивать apex, то лучше написать про weblogic, ну или на худой конец glassfish. Хотя, последний, непонятно какой версии использовать. Если 3й, то вроде как устарел, если 4й, то вроде как не комильфо… потому что не кошерное оно…
В общем, weblogic наше все. И статья полезней бы была, так как weblogic не так просто развернуть, как glassfish, ну по крайней мере, не так все очевидно… Особенно, интересно было бы описать, как ssl на weblogic поднять, так как опять таки, не все тривиально… и новички могут набить шишки на таких вещах.
В общем, мое мнение, что использование apache/nginx для apex это прошлый век. Прошу прощения за категоричность.
Сегодня настроил Akeeba backup.
Есть несколько замечаний, верней дополнений к статье:

1) Если в настройках установить ZIP формат архива ( у меня joomla 3.2 и последняя версия akeeba backup), то архив разворачивается так:
а) создаем на нужном сервере http папку, например /srv/www/htdocs, в которую копируем zip архив с бакапом
б) распаковываем в папке архив так — unzip backup.zip
в) создаем пустую базу данных, пользователя с паролем и правами доступа к базе на нашем новом сервере
г) просто входим на сайт www.site.com и видим, что из распакованной папки installation автоматически запустился установщик, а это значит что не нужно использовать kickstart, скачивая его для восстановления. Архив уже содержит все в себе. Не забываем настроить на сервере индекс для обработки файла index.php по умолчанию. К примеру, для nginx — добавим в конфиг index index.php, но думаю, что это не нужно разжевывать.

2) akeeba backup стоит 40$ или евро, не помню. Его можно использовать бесплатно, но тогда нет автоматизации по отправке архивов на амазон например. Мне на амазон и не нужно. Мне нужно, чтобы бакапы копировались на сторонний сервер, чтобы, если упадет основной сервер, например с помощью rm -fr от корня, то я мог бы использовать архив со своего второго сервера.
Что делать? Ответ здесь:
а) на второй сервер ( у нас ведь там юникс, линукс не так ли? ) копируем с akeeba сайта remote cli, специальный файл, который умеет коннектиться к основному сайту.
б) настраиваем крон 0 3 * * * /backups/get_backup.sh > /dev/null 2>&1
содержимое файла get_backup.sh

#!/usr/bin/sh
cd /backups
/usr/bin/php remote.phar --action=backup --host=http://www.site.com --secret=mysecretfromsite --profile=1 --download --dlmode=http --dlpath="/backups/"

в) далее, не забываем сделать chmod +x для /backups/get_backup.sh и ручками запускаем его, для тестирования. В случае ругани, не забываем что нужно добавить необходимые библиотеки для php и прописать папку /backups в PEAR для php.ini

Собственно все. Как это работает:
1) Сервер 2 коннектится к серверу 1 и создает на сервере 1 согласно профилю 1 ( это описано в статье выше ) бакап.
2) Далее, сервер 2 скачивает в папку /backups сервера 2 архив с сервера 1, который только что был создан

Ура. Мы имеем в папке /backups архивы за каждый день. Как удалять старые, не буду описывать, мне это не нужно. Пусть себе живут. Скрипт на шеле, думаю легко написать с помощью гугла.

Информация

В рейтинге
Не участвует
Откуда
Выборг, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность