განთავსება Zinnector®-ით: დაკავშირება, შემოწმება, გაგზავნა

როგორც კი პროექტი ლოკალურად გაეშვება, ოთხი ბრძანება მას Zinn Digital®-ის ჰოსტინგის აქტიურ საიტზე გადაიტანს: შესვლა, პროექტის დაკავშირება ჰოსტინგის სლოტთან, წინასწარი შემოწმების (pre-flight) წაკითხვა და push. ეს სტატია დეტალურად განიხილავს თითოეულ მათგანს, თუ რას ბეჭდავენ ისინი და ბრძანებებს, რომლებსაც შემდგომ იყენებთ — ხელახალი დეპლოი, დეპლოის ისტორია და build-ის ლოგები.

შესვლა API გასაღებით

შექმენით გასაღები სამართავ პანელში შემდეგ მისამართზე: Settings → API keys, შემდეგ:

zinnector login

გასაღები იკრიფება მოთხოვნისას — ის არასდროს მიიღება ბრძანების სტრიქონში, რათა არ მოხვდეს თქვენი shell-ის ისტორიაში ან პროცესების სიაში. CI-ში გადაეცით ის pipe-ით: echo "$ZINN_API_KEY" | zinnector login --profile ci, ან განსაზღვრეთ ZINNECTOR_TOKEN და მთლიანად გამოტოვეთ login. გასაღები მოწმდება შენახვამდე და ინახება ფაილის რეჟიმით 600. zinnector whoami --scopes აჩვენებს, თუ რომელ ორგანიზაციაში ხართ შესული და რა უფლებებს ატარებს გასაღები; sandbox-ის გასაღები შესაბამისად არის მონიშნული.

პროექტის დაკავშირება სლოტთან

zinnector link                                   # pick a site from a list
zinnector link example.com --repo acme/site --branch main

link წერს საიტის id-ს zinnector.json-ში და, თუ არ გადასცემთ --no-repo-ს, აკავშირებს პროექტის git remote-ს პლატფორმაზე არსებულ საიტთან, რათა push-მა განახორციელოს მისი დეპლოი. დააკომიტეთ zinnector.json: კოლეგა, რომელიც რეპოზიტორიის კლონირებას მოახდენს, შემდეგ იმავე ადგილას განათავსებს დეპლოის დამატებითი მითითებების გარეშე. ის არ შეიცავს საიდუმლო ინფორმაციას.

წაიკითხეთ წინასწარი შემოწმება (pre-flight)

zinnector check

ეს არის ბრძანება, რისთვისაც CLI არსებობს. ის ადარებს თქვენს პროექტს იმ სლოტთან, რომელზეც იგეგმება დეპლოი, და ბეჭდავს ყველა შეუსაბამობას — და ყველა იმ შედარებას, რომლის გაკეთებაც ვერ შეძლო:

• PHP ვერსია, სადაც ძირითადი ვერსიის სხვაობა ფასდება როგორც high, რადგან ის გარანტირებულად აზიანებს საიტს, ხოლო მცირე სხვაობა უფრო დაბალი დონით ფასდება, რადგან ყველაფრის კრიტიკულად შეფასება მომხმარებლებს აჩვევს გაფრთხილების უგულებელყოფას.
• შეუძლია თუ არა სლოტს გადართვა იმ ვერსიაზე, რომელზეც შექმენით პროექტი, არის თუ არა სლოტის PHP მხარდაჭერის ვადის გასვლის შემდეგ, და სისტემამ გამოიყენა ეს ვერსია თუ მხოლოდ შეტყობინება მიიღო.
• თქვენი პროექტის ზომა და ფაილების რაოდენობა სლოტზე რეალურად დარჩენილ დისკის სივრცესთან და inode-ის მარაგთან შედარებით — WordPress-ის ხემ შესაძლოა ამოწუროს ფაილების ლიმიტი მაშინ, როცა დისკის ლიმიტამდე ჯერ კიდევ ბევრია დარჩენილი.
• WordPress-ის ვერსიები თითოეულ მხარეს, დასრულდა თუ არა სლოტის პროვიზიონინგი (provisioning), და არის თუ არა რეპოზიტორი დაკავშირებული push-ისთვის.

ის აფრთხილებს; ის არასდროს ბლოკავს. ნებისმიერი მიგნება გადალახვადია ბრძანებით zinnector push --force, რადგან თქვენ იცით საკუთარი საიტის შესახებ ისეთი დეტალები, რომლებიც შემმოწმებელმა არ იცის. შედარება, რომლის გაკეთებაც ვერ მოხერხდა, აღირიცხება როგორც unknown და არასდროს როგორც წარმატებული (pass), ხოლო შეჯამება ყოველთვის მიუთითებს მათ რაოდენობას. ნაგულისხმევად, ლოკალური PHP ვერსია არის ის, რაც დეკლარირებულია zinnector.json-ში; --probe უშვებს ლოკალურ გარემოს და ნაცვლად ამისა ზომავს მას. --strict ასევე არანულოვანი სტატუსით სრულდება უცნობ შედეგებზეც, რაც სწორედ CI-ის შემოწმებისთვისაა საჭირო.

Push

zinnector push

push უშვებს წინასწარ შემოწმებას (pre-flight), აგზავნის თქვენს კომიტებს, ააქტიურებს დეპლოის და აკვირდება მის დასრულებას, ბეჭდავს საბოლოო სტატუსსა და დეპლოირებულ კომიტს. --dry-run აკეთებს ყველაფერს დეპლოის გარდა; --no-wait ააქტიურებს მას და ასრულებს მუშაობას; --no-git ახდენს იმის დეპლოის, რაც პლატფორმას უკვე აქვს, push-ის გარეშე. თუ დეპლოირებული კომიტი არ ემთხვევა ახლახან გაგზავნილს, ის გაცნობებთ ამის შესახებ.

როდესაც რაღაც არასწორად მიდის

zinnector deploys example.com        # deploy history — status, commit, trigger, message
zinnector logs example.com --build   # the build log of the most recent deploy
zinnector logs example.com --error   # the site's error log
zinnector deploy example.com         # redeploy what the platform already has
zinnector ai "why is my deploy failing?"

zinnector ai ეშვება პლატფორმაზე თქვენივე ანგარიშის ფარგლებში, ასე რომ, მას შეუძლია ნახოს დეპლოის იგივე ისტორია და ლოგები. პროექტის შიგნიდან ის აგზავნის პროექტის სტრუქტურას — დირექტორიის სახელებს, ვერსიებსა და საიტის id-ს — და არასდროს ფაილების შიგთავსს.

დაკავშირებული

• დაწყება · ლოკალური დეველოპმენტი · ბრძანებების ცნობარი · პრობლემების გადაჭრა