Що се отнася до актуализирането на приложение на живо, има два фундаментално различни начина за това.

При първия подход правим постепенни промени в състоянието на нашата система. Например актуализираме файлове, модифицираме свойствата на средата, инсталираме допълнителни нужди и т.н. Във втория подход ние разрушаваме цели машини и възстановяваме системата с нови изображения и декларативни конфигурации (например, използвайки Kubernetes).

Разполагането на Laravel стана лесно

Тази статия обхваща основно относително малки приложения, които може да не се хостват в облака, въпреки че ще спомена как Kubernetes може да помогне много ние с внедряване извън сценария „без облак“. Също така ще обсъдим някои общи проблеми и съвети за извършване на успешни актуализации, които могат да бъдат приложими в редица различни ситуации, не само при внедряването на Laravel.

За целите на тази демонстрация ще използвам Laravel например, но имайте предвид, че всяко PHP приложение може да използва подобен подход.

Версиониране

За начало е от решаващо значение да знаем версията на кода, която в момента е внедрена в производството. Той може да бъде включен в някакъв файл или поне в името на папка или файл. Що се отнася до именуването, ако следваме стандартната практика на семантична версия , можем да включим в него повече информация, отколкото само едно число.

Разглеждайки две различни версии, тази добавена информация може да ни помогне лесно да разберем естеството на промените, въведени между тях.

Версионирането на изданието започва със система за контрол на версиите, като Git. Да приемем, че сме подготвили версия за внедряване, например версия 1.0.3. Що се отнася до организирането на тези издания и потоци на код, има различни стилове на разработка като базирано на багажника развитие и Git поток , които можете да изберете или смесите въз основа на предпочитанията на вашия екип и спецификата на вашия проект. В крайна сметка най-вероятно ще завършим с нашите издания, маркирани съответно в нашия основен клон.

След фиксирането можем да създадем прост таг като този:

git tag v1.0.3

И тогава включваме тагове, докато изпълняваме командата push:

гещалт принципите на организацията

git push --tags

Можем също да добавяме тагове към старите фикси, използвайки техните хешове.

Получаване на файлове за освобождаване до тяхната дестинация

Разгръщането на Laravel отнема време, дори ако е просто копиране на файлове. Въпреки това, дори и да не отнеме твърде много време, нашата цел е да постигнем нулев престой .

Ето защо трябва да избягваме инсталирането на актуализацията на място и не трябва да променяме файловете, които се обслужват на живо. Вместо това трябва да разположим в друга директория и да извършим превключването само след като инсталацията е напълно готова.

Всъщност има различни инструменти и услуги, които могат да ни помогнат при внедряването, като Пратеник.io (от дизайнера на Laravel.com Джак Макдейд), Капистрано , Разполагащ и др. Все още не съм използвал всички от тях в производството, така че не мога да давам препоръки или да напиша цялостно сравнение, но нека да представя идеята зад тези продукти. Ако някои (или всички) от тях не могат да отговорят на вашите изисквания, винаги можете да създадете свои персонализирани скриптове, за да автоматизирате процеса по най-добрия начин, който сметнете за добре.

За целите на тази демонстрация, да кажем, че нашето приложение Laravel се обслужва от сървър на Nginx от следния път:

/var/www/demo/public

настройка на производителността на базата данни на sql сървъра

Първо, имаме нужда от директория, в която да поставяме файлове за освобождаване всеки път, когато правим внедряване. Също така се нуждаем от символна връзка, която да сочи към текущата работна версия. В този случай, /var/www/demo ще служи като нашата символна връзка. Преназначаването на показалеца ще ни позволи бързо да променяме изданията.

В случай, че имаме работа със сървър на Apache, може да се наложи да разрешим следните символни връзки в конфигурацията:

Options +FollowSymLinks

Нашата структура може да бъде нещо подобно:

/opt/demo/release/v0.1.0 /opt/demo/release/v0.1.1 /opt/demo/release/v0.1.2

Възможно е да има някои файлове, които трябва да продължим чрез различни внедрявания, например лог файлове (ако очевидно не използваме Logstash). В случай на внедряване на Laravel, може да поискаме да запазим директорията за съхранение и конфигурационния файл .env. Можем да ги държим отделени от други файлове и вместо това да използваме техните символни връзки.

За да извлечем нашите файлове за освобождаване от хранилището на Git, можем да използваме команди за клониране или архивиране. Някои хора използват git clone, но не можете да клонирате определен ангажимент или маркер. Това означава, че цялото хранилище е извлечено и след това е избран конкретният маркер. Когато хранилището съдържа много клонове или голяма история, размерът му е значително по-голям от архива на изданието. Така че, ако не се нуждаете конкретно от git repo при производството, можете да използвате git archive. Това ни позволява да извлечем само файлов архив от определен маркер. Друго предимство на използването на последното е, че можем да игнорираме някои файлове и папки, които не трябва да присъстват в производствената среда, например тестове. За това просто трябва да зададем свойството export-ignore в .gitattributes file. В Контролен списък на практиките за безопасно кодиране на OWASP можете да намерите следната препоръка: „Премахнете тестовия код или всяка функционалност, която не е предназначена за производство, преди внедряването.“

Ако извличаме съобщението от системата за контрол на версиите на източника, git archive и export-ignore може да ни помогнат с това изискване.

Нека да разгледаме опростен скрипт (ще се нуждае от по-добро обработване на грешки в производството):

разлика между agile scrum и kanban

разполагане.sh

#!/bin/bash # Terminate execution if any command fails set -e # Get tag from a script argument TAG= GIT_REMOTE_URL='here should be a remote url of the repo' BASE_DIR=/opt/demo # Create folder structure for releases if necessary RELEASE_DIR=$BASE_DIR/releases/$TAG mkdir -p $RELEASE_DIR mkdir -p $BASE_DIR/storage cd $RELEASE_DIR # Fetch the release files from git as a tar archive and unzip git archive --remote=$GIT_REMOTE_URL --format=tar $TAG | tar xf - # Install laravel dependencies with composer composer install -o --no-interaction --no-dev # Create symlinks to `storage` and `.env` ln -sf $BASE_DIR/.env ./ rm -rf storage && ln -sf $BASE_DIR/storage ./ # Run database migrations php artisan migrate --no-interaction --force # Run optimization commands for laravel php artisan optimize php artisan cache:clear php artisan route:cache php artisan view:clear php artisan config:cache # Remove existing directory or symlink for the release and create a new one. NGINX_DIR=/var/www/public mkdir -p $NGINX_DIR rm -f $NGINX_DIR/demo ln -sf $RELEASE_DIR $NGINX_DIR/demo

За разгръщане на нашата версия можем просто да изпълним следното:

deploy.sh v1.0.3

Забележка: В този пример v1.0.3 е git тагът на нашата версия.

Композитор на продукция?

Може би сте забелязали, че скриптът извиква Composer за инсталиране на зависимости. Въпреки че виждате това в много статии, може да има някои проблеми с този подход. Като цяло е най-добрата практика да създадете цялостно компилиране на приложение и да го подобрите чрез различни тестови среди на вашата инфраструктура. В крайна сметка ще имате щателно тествана компилация, която може безопасно да бъде внедрена в производството. Въпреки че всяка компилация трябва да бъде възпроизводима от нулата, това не означава, че трябва да възстановяваме приложението на различни етапи. Когато правим инсталацията на композитор да се произвежда, това наистина не е същата компилация като тестваната и ето какво може да се обърка:

• Мрежовата грешка може да прекъсне изтеглянето на зависимости.
• Доставчикът на библиотека не винаги може да следва SemVer.

Лесно може да се забележи мрежова грешка. Нашият скрипт дори би спрял да се изпълнява с грешка. Но пробивна промяна в библиотеката може да бъде много трудно да се определи без провеждане на тестове, което не можете да направите в производството. Докато инсталират зависимости, Composer, npm и други подобни инструменти разчитат на семантично управление на версии – major.minor.patch. Ако видите ~ 1.0.2 в composer.json, това означава да инсталирате версия 1.0.2 или най-новата версия на корекцията, като 1.0.4. Ако видите ^ 1.0.2, това означава да инсталирате версия 1.0.2 или най-новата малка версия или версия на корекцията, като 1.1.0. Надяваме се, че доставчикът на библиотеки ще увеличи основния брой, когато се въведе някаква промяна на счупването, но понякога това изискване се пропуска или не се спазва. В миналото е имало такива случаи. Дори ако поставите фиксирани версии във вашия composer.json, вашите зависимости може да имат ~ и ^ в техния composer.json.

Ако е достъпен, по мое мнение, по-добър начин би бил използването на артефактно хранилище ( Nexus , JFrog и т.н.). Версията за издание, съдържаща всички необходими зависимости, ще бъде създадена веднъж, първоначално. Този артефакт ще се съхранява в хранилище и ще се извлича за различни етапи на тестване от там. Също така, това би било компилацията, която да бъде внедрена в продукцията, вместо да се възстановява приложението от Git.

Поддържане на съвместимост на кода и базата данни

Причината, поради която се влюбих в Laravel от пръв поглед, беше как авторът му обърна голямо внимание на детайлите, помисли за удобството на разработчиците и също така включи много най-добри практики в рамката, като миграции на бази данни.

Миграциите на бази данни ни позволяват да синхронизираме нашата база данни и код. И двете им промени могат да бъдат включени в един ангажимент, следователно едно издание. Това обаче не означава, че всяка промяна може да бъде внедрена без престой. По някое време по време на внедряването ще има различни версии на приложението и базата данни. В случай на проблеми тази точка може дори да се превърне в точка. Винаги трябва да се опитваме да направим и двете съвместими с предишните версии на техните спътници: стара база данни - ново приложение, нова база данни - старо приложение.

Да кажем например, че имаме address колона и трябва да я разделите на address1 и address2. За да запазим всичко съвместимо, може да се нуждаем от няколко версии.

1. Добавете две нови колони в базата данни.
2. Променете приложението, за да използвате нови полета, когато е възможно.
3. Мигриране address данни в нови колони и ги пуснете.

Този случай също е добър пример за това как малките промени са много по-добри за внедряване. Връщането им също е по-лесно. Ако променяме кодовата база и базата данни в продължение на няколко седмици или месеци, може да е невъзможно да актуализираме производствената система без престой.

Някаква страхотност на Кубернети

Въпреки че мащабът на нашето приложение може да не се нуждае от облаци, възли и Kubernetes, все пак бих искал да спомена как изглеждат внедряванията в K8s. В този случай ние не правим промени в системата, а по-скоро декларираме какво бихме искали да постигнем и какво трябва да работи на колко реплики. След това Kubernetes се уверява, че действителното състояние съответства на желаното.

качество на данните в хранилището за данни

Винаги, когато имаме готова нова версия, ние изграждаме изображение с нови файлове в него, маркираме изображението с новата версия и го предаваме на K8s. Последният бързо ще завърти изображението ни в клъстер. Ще изчака, преди приложението да е готово въз основа на проверката за готовност, която предоставяме, след това незабележимо да пренасочи трафика към новото приложение и да убие старото. Можем много лесно да стартираме няколко версии на нашето приложение, което ще ни позволи да изпълняваме синьо / зелено или канарче разгръщане само с няколко команди.

Ако се интересувате, има няколко впечатляващи демонстрации в беседата „ 9 стъпки към страхотно с Kubernetes от Бър Сътър . '

Свързани: Пълно удостоверяване на потребителя и контрол на достъпа - Урок за паспорт на Laravel, Pt. 1

Разбиране на основите

Какво представлява Laravel и защо се използва?

Laravel е опитна PHP рамка с MVC архитектура, предоставяща съвременни инструменти и изразителен синтаксис за бързо разработване, поддръжка, тестване и, следователно, по-кратки цикли на издаване.

Популярен ли е Laravel?

Според класациите за 2019 г. Laravel е на върха в списъка като най-популярната PHP рамка.

Какви са предимствата на Laravel?

Красноречивият ORM, плавен конструктор на заявки, страхотна документация и винаги актуални Laracasts определено правят рамката да се откроява. Laravel включва автоматизация и бързо развитие с предоставяне на инструменти като Artisan.