28 августа 2019 в 12:46
Всем привет. Форумчане, если правильно слушал ваши разговоры ядро Durpal-а может обновляться автоматически, при выходе новых версий?
И делается это через Composer?
Дайте пожалуйста ссылку, как это настроить. С сохранением .htaccess, robots.txt если можно.
https://www.drupal.org/project/autoupdate - а этот модуль нужен тогда?
28 августа 2019 в 12:50
В автоматическом обновлении нет необходимости, т.к. нормальные люди сначала обновляют ядро на локалке/деве, тестируют, а потом уже с помощью composer install ядро обновляется на проде.
Для любителей bdsm можно настроить в кроне сервера ежедневный запуск composer update и тогда всё будет обновляться автоматически. И ядро и контриб и вендоры
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Комментарии
В автоматическом обновлении нет необходимости, т.к. нормальные люди сначала обновляют ядро на локалке/деве, тестируют, а потом уже с помощью composer install ядро обновляется на проде.
Для любителей bdsm можно настроить в кроне сервера ежедневный запуск composer update и тогда всё будет обновляться автоматически. И ядро и контриб и вендоры
Ядро Друпала не может обновляться автоматически (
хвала Дрису!)Но, можно настроить скрипт автоматического обновления, который будет следить за обновлениями, в т.ч. используя композер для этих целей.
На самом деле, это шаг к практикам CI / CD, которые могут содержать подобную логику.
В хорошо спроектированной, сферической системе в вакууме, покрытие тестов которой позволяет рассчитывать на выявление всех ошибок (что на практике не осуществимо), может содержаться скрипт реализующий:
Вариантов запуска - море, от CLI'шных комманд, с автозапуском по крону, до использования специализированных сервисов.
ЗЫ - про модуль ХЗ, никогда, низачто не доверил бы контрибу подобное.
Голосую за этот вариант, ибо так и делаю. Проверяю обновления на локальной установке:
Если есть обновления, то:
Чистим кеш:
Проверяем работу админки и главной страницы. Если все работает, делаю обновление на vps. Был случай, обновил друпал на локалке, и он умер ). Откатился назад. Через некоторое время снова обновился, и работа друпала была корректной.
Не забываем заходить в "Отчеты -> Отчет о состоянии" и обновлять базу данных, если сие требуется. Автоматическое обновление через крон - крайне опасно. Можно обновится, и получить сбой, а откатываться будет некуда.
"а откатываться будет некуда" - бекап БД и файлов - разве не решат?
Форумчане, я не агитирую за обновление через Композер. Тему создал потому, как был топик про обновление и кто-то написал "У меня Композер на автообновление настроен". Не помню кто это был. Но вот мнение его сейчас интересно стало.
Может быть речь шла об автоматическом накате ядерных патчей после каждого обновления ядра? Для меня эта фича является одним из основных мотиваторов когда-нибудь перетащить сайт под композер.
Может быть. Спасибо.
Вполне вероятно что, я неправильно понял о чем была речь.
Решает. Если он суточный. Можно в крон забить "composer update", но я бы так не делал.
Не нужен никакой суточный бэкап. Старые версии composer.json и composer.lock лежат в гите, а бэкап базы можно сделать перед drush updb. Причём если обновлять на локалке, то можно с бэкапом бд вообще не заморачиваться, т.к. при необходимости его всегда можно слить с продакшена.
Вообще, автоматическое обновление можно делать только в одном случае: когда есть тестовый сервер с настроенной CI-системой, которая после обновления будет автоматически запускать все необходимые тесты и только в случае успешных тестов будет делать автоматический коммит, который инициирует на продакшн composer install и drush updb. Прошу обратить внимание, именно инсталл, а не апдейт.
По поводу набора тестов: я бы не стал запускать все ядерные и контрибные тесты. На мой взгляд, достаточно написать acceptance-тесты под каждый тип страниц на сайте, просто на получение 200 ответа, плюс тесты с нажатием ключевых кнопок. Если всего этого не сделать, то несколько раз в год сайт будет лежать по несколько часов в самое неудобное для разработчика время.
Я заводил так несколько раз на малозначимых своих проектах, правда проверял не код ответа а получение определенного контента (копирайты проверял) с главной. Но потом убрал. Что-то там было неочевидное. либо надо тестами покрывать сильнее (как минимум еще диффы скринов страниц до/после обновления).
Диффы скринов тоже нужно, но на практике вёрстка не так уж часто слетает при обновлении.
А вообще как там у вас в радоне, полностью автоматическое обновление существует в принципе или нет?
Клиентских в полностью автоматическом режиме нет. Так чтобы обновить пачку сайтов разом - да, но надо лично пойти посмотреть результаты. Временами между 8.x.y-8.x+1.y версиями есть затыки. Но со временем и с опытом все быстрее и быстрее)
Мы минимизировали ручное время. Config split для разных типов сайтов, gitlab + тесты.
Допустим на хостинге сайт устновленный через Composer и я понятия не имею что такое Composer. Максимум, что я вижу: есть папка web из которой сайт работает.
Вопрос: можно ли перенести сайт на другой хостинг просто перенеся файлы (с папкой web и выше) и БД?
Да я знаю про git, сейчас вопрос не в этом.
Можно.
Не всегда. Нужно чтоб окружение было одинаковым, т.к. некоторые библиотеки могут ставиться с учетом, например, версий PHP или наличия / отсутствия определенных расширений и инструментов.
Как минимум, перестанут работать вендорные бинарники, т.к. они ссылками и пути не скопируются.
Ну, и желательно сделать сделать хоть
В теории это так, а на практике я недавно заметил, что у меня в докере на локалке пых 7.2, а на дев-сервере 7.1. Почти год не было никаких проблем и это никак не проявлялось.
Мое дело - предупредить и рассказать как правильнее.
Так-то я и сам могу юзать компоненты от 7.3 на 7.1. Но, когда знаешь что там может пойти не так - это одно, а когда "я понятия не имею что такое Composer" и вылазит 500я - это больно.
Хорошо, можно ссылку на инструкцию как переносить композированные сайты между хостингами правильно?
1. Перенести БД любым способом
2. Git clone с репозитория
3. Composer install
4. Каталог с файлами перенести вручную, тк в большинстве случаев каталог с файлами добавлен в gitignore
Всё то же самое, что и при первом развертывании сайта
Ну ок, поехали. Захожу в папку сайта у себя на ПК
$ git init
$ git add .
$ git commit -m "Подготавливаем к переносу"
[master (root-commit) a958fce] Подготавливаем к переносу
235 files changed, 41424 insertions(+)
create mode 100644 .editorconfig
create mode 100644 .env.example
...
В какой папке делать инит? В папке сайта или в папке web? Чето мне кажеться, что в папке web, иначе како смысл делать composer install потом. Я прав?
Ответы на все эти вопросы давно разжеваны в первых видео Никлана на ютубе. Не вижу смысла повторяться.
Нет, надо в папке выше web. Вендоры и контрибы в гитигнор добавлены по умолчанию.
Разберись с предметом, и не нужно будет искать всякую чушь.
В папке выше web+
Видео Никиты... Смотреть про программирование, это все равно что нюхать музыку.
Смотрел конечно же. А есть текстовая информация как это (https://niklan.net/blog/186) делать?
Докер тоже ставить?
https://git-scm.com/book/ru/v1/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B...
Там разве про Друпал и Композер есть?
https://githowto.com - читал это но там тоже нет, хоть автор и друпалер.
У тебя сейчас вопросы по гиту. Он ни к Друпалу, ни к Композеру не имеет отношения.
Слишком много всего. В голове не укладывается
Ладно пока клонирую сайт в пределах одного окружения потом уже по хостингам буду разносить.
$ git clone d8.my d82.my
$ cd d82.my
$ composer install
(пью кофе)
Копирую папку files из одного сайта в другой.
Клонирую БД.
Устанавливаю Drupal в клонированный сайт указывая БД.
Вроде заработало. Если правильно понимаю папку web\sites\ тоже в гитигнор добавить?
Если ты клонируешь БД, то ничего устанавливать уже не надо (сайт ведь на локалке уже установлен)
Она там по умолчанию
Списибо, увидел
Теперь вопрос: как перетаскивать файлы с моего ПК на хостинг? Можно даже ссылку на конкретный раздел в документации.
Это оно (?).
https://githowto.com/ru/hosting_your_git_repositories
https://nano.sapegin.ru/all/deploy/
https://hyperhost.ua/info/kak-zagruzit-faylyi-na-udalennyiy-repozitoriy-...
Неужели команда типа git clone git://localhost/hello.git network_hello на хостинге будет работать?
На Github регистрироваться обязательно?
Лучше всего использовать GitHab или GitLab как промежуточный сервер. И там и там сейчас можно создавать приватные репозитории
А без них можно? Зачем это промежуточное звено? Почему нельзя сразу с ПК на хост?
А как ты себе это представляешь? Ну можешь поднять vps, а на нем свой гит сервер, если не доверяешь гитхабу и гитлабу. Но ты опять создашь себе трудности и будешь их героически преодолевать
Читай про баре репозитории
Как представляю: ПК к интернету подключен, хостинг тоже к интернету подключен. Неужели фантазии нездоровые?
Баре репозитории...
https://githowto.com/ru/bare_repositories - не вижу, как это связано с Github и целевым хостингом.
https://git-scm.com/book/ru/v1/Git-%D0%BD%D0%B0-%D1%81%D0%B5%D1%80%D0%B2... - тут вроде бы целевой сервер расматривается, но про Github не вижу.
Что тебе нужно от хаба?
Как я понял из комментов выше использовать его как промежуточное звено между ПК и хостингом.
Определись! Ты спрашиваешь "как без ГХ", я тебе пишу "делай баре", ты спрашиваешь "какая связь у баре и ГХ".
Почитай внимательно, ознакомься с технологией, попробуй ее в действии, потом пробуй инструменты - всякие хабы.
Найди видос на YT, в конце-концов. Куча материала где все разжевывают и раскладывают по полочкам.
Потом, если остануться вопросы - задавай.
т.е. баре - это закачивать без Гитхаба? Понятно. bumble вот искал на Ютюбе, но пока не вижу, чтобы кто-то перебрасывал Composer caйт со своего ПК на Хост через Гитхаб. Да еще и с
семейнымсистемным окружением как у меня. Все до чего я дошел написал в нижнем комменте по ветке.Когда разберешься, поймешь что баре-репозитории, это такие, в которые можно делать пуш.
А откуда стягивать (фетч) - значения не имеет, будь то репозиторий в соседней директории, или на удаленном сервере.
Снова, в кучу пытаешься складывать все, что должно быть по разным кучам. Композер - не имеет отношения к гиту:
Но! Я уверен что есть куча людей, которые пилят кучу видосов, в которых показывают как они разворачивают композером проекты, вытянутые из репозиториев всевозможных сервисов, в т.ч. с Гитхаба. Шукай краще!
ЗЫ - молодец что стараешься!
Я считаю, что да, потому простейшая ситуация работы с гит это
git push с локалки - промежуточный сервер - git pull на хостинг
Огромный плюс удалённого репозитория - надёжная резервная копия кода. А то постоянно такое - на продакшн всё съел очередной друпалгедон, а старый комп уже в мусорке.
В целом согласен, хотя полноценным бэкапом его нельзя назвать, т.к. сайт это не только файлы, но в большей степени и БД
Шаг первый, заходим на шаред хостинг по ssh:
Второй шаг, копируем файлы друпала:
Третье: делаем архив:
Скачиваем сей на свой пека:
Делаем копию базы данных и скачиваем на свой пека:
Теперь загружаем файлы друпал на шаред хостинг или vps по ssh:
Распаковываем файлы:
Загружаем базу:
Задаем настройки базы данных:
Если нужно, восстанавливаем владельца директорий и файлов:
Чистим кеш:
Обновляем друпал через композитор
Проверяем работу в браузере. Сколько раз делал, всегда работает. Можно конечно вот это вот CI/CD, Gitlab, Github. Но это такой геморрой. Пока это изучишь и вникнешь как работает, поседеешь... Есть компании, группы разработчиков, они без CI/CD не смогут просто работать. Если тебе надо ТОЛЬКО перенести сайтек, накатить обновления, можно и без CI/CD, Gitlab, Github.
Это называется профессиональный рост. Те, кто не растут и не идут в ногу со временем, рано или поздно окажутся за бортом
Да я же не против. Если парень работает в организации. Пишет код. Это его обязанность уметь непрерывную разработку и интеграцию. Но если ему нужно как хобби, а не как специалист/разработчик, проще перекинуть файлы и базу.
Я фрилансер на данный момент. Смело заявляю, что git и composer экономят моё время. Плюс когда я беру сайт на поддержку, а он собран с помощью composer, то я не седею, а работаю с ним в привычном ритме
Во-первых, composer update на шареде с 99% вероятностью не пройдёт. Во-вторых, такой метод хорош только в том случае, когда ты можешь с первого раза сделать такой сайт, код которого не придётся править никогда.
Я не разработчик, не фрилансер, и спорить не собираюсь. Если ты специалист, пишешь код, ты обязан знать уметь CI/CD. НО ЕСЛИ ТЕБЕ ПРОСТО ПЕРЕКИНУТЬ. Можно перекинуть вручную.
"просто перекинуть" - очень странная постановка задачи. Непонятно, при каких условиях она может возникнуть?
Sergey F, спасибо, за моральную поддержку!
Не совсем пониаю зачем на первом шаге, заходить на хостинг и оттуда что-то скачивать. Моя задача - заказчать сайт на хостинг.
Листин примерно понял, это я (уже, по моим комментам выше) умею. Но на данном этапе своей эволюции разбираюсь с Гитом.
Итак до чего я пока дошел. Видите ошибку - напишите.
github
Захожу на сайт github, создаю новый репозиторий.
Опции:
На своем ПК
$ git push -u origin master
Username for 'https://github.com': Vasy0K
Password for 'https://Vasy0K@github.com': [не копируется]
Counting objects: 248, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (235/235), done.
Writing objects: 100% (248/248), 1.80 MiB | 728.00 KiB/s, done.
Total 248 (delta 14), reused 0 (delta 0)
remote: Resolving deltas: 100% (14/14), done.
To https://github.com/Vasy0K/glyanec.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
На хостинге
Cloning into 'dev.u14040.krypton2.vps-private.net'...
Username for 'https://github.com': Vasy0K
Password for 'https://Vasy0K@github.com': [ну не копируется оно сюда]
remote: Enumerating objects: 248, done.
remote: Counting objects: 100% (248/248), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 248 (delta 14), reused 248 (delta 14), pack-reused 0
Receiving objects: 100% (248/248), 1.80 MiB | 1.12 MiB/s, done.
Resolving deltas: 100% (14/14), done.
Вроде бы закачалось с Гитхаба. Инициирую Composer.
u14040@krypton ~/domains/dev.u14040.krypton2.vps-private.net $ php72 /usr/bin/composer installКак вижу файлы сайта на хостинг закачались. Теперь на хостинге устанавливать Друпал и экспортировать конфигурацию с дев сайта на моем ПК?
Теперь надо перелить базу и папку с картинками. Конфу экспортируют не при первичном развёртывании, а в процессе. Ну типа подкрутил вьюху на локалке, экспортнул, закоммитил, запушил, а на серваке пулл и импорт.
перелить базу и папку с картинками +
Допустим сайт уже в прцессе. И мне дано задание: сделать страницу Сотрудники.
Экспортирую полную конфигурацию на одном сайте импортирую на другом. Вроде бы все переносится (вьюхи, типы материалов) кроме нод. Как быть?
Не создавать контент на деве, раз он не переносится. Это же очевидно.
Есть лайфхак - создать одну рыбную ноду, а во вьюхах прямо в девтулзах её размножить, сделать заголовки разной длины и всё такое.
Расскажи подробнее)
Да что там рассказывать? Открываешь девтулзы, выделяешь views-row, выбираешь "править как html", зажимаешь ctrl, и последовательно жмёшь ACVVVVVVVVVVV, и всё, во вьюхе уже 100500 одинаковых записей. При необходимости, текст в каждом элементе меняется по двойному клику по тексту в "просмотре кода". Если верстать по нормальному с хот-релоадом, то при обновлении стилей вся эта фигня не слетает и можно спокойно верстать страницу хоть целый день.
Вроде немного освоился. Можете объяснить (без сильно умных слов): какой от Докера мне будет профит? Сейчас на Опенсервере делаю. Гит и Композер под ConEmu запускаю.
А какой профит ты ожидаешь?
На вскидку - будет освоена новая технология. Левелап == профит.
Если докер на винде, то проще на OpenServer сидеть. А так де, как написал bumble, еще одна освоенная технология и опыт.
Опыт ради опыта? Я так не умею учится.
Мне надо чтоб проблема была какая-то решена с помощью ПО.
Опыт ради повышения квалификации и повышения заработка. Или деньги тебя не интересуют?
Найди проблему, решаемую получением этого опыта - и реши ее.