Ghost-ის ბლოგის ჰოსტინგი: ინსტალაცია, ფოსტა, თემები, backup-ი და განახლება

საკუთარ სერვერზე Ghost-ის ბლოგს იმაზე ნაკლები სჭირდება, ვიდრე ხალხი ელის: დაახლოებით 1 GB მეხსიერება პირადი საიტისთვის, დომენი HTTPS-ით მის წინ, პარამეტრი url, რომელიც ზუსტად ემთხვევა ამ დომენს, და მომუშავე გამავალი ფოსტა. ბოლო ორ პუნქტზე ფუჭდება Ghost-ის თითქმის ყველა გაფუჭებული ინსტალაცია. მისამართი და ფოსტა პირველივე დღეს სწორად დააყენე, საქაღალდე content-ის ასლი სერვერის გარდა სხვაგანაც შეინახე, და დანარჩენი - თემები, წევრები, newsletter-ები, განახლებები - ადმინის ეკრანში ჩვეულებრივი სამუშაოა.

ეს სახელმძღვანელო განიხილავს, რისგან შედგება Ghost სერვერზე სინამდვილეში, რა ზომის სერვერი სჭირდება, იმ რამდენიმე პარამეტრს, რომლებსაც მართლა აქვს მნიშვნელობა, განსხვავებას იმ ორ სახის წერილს შორის, რომლებსაც Ghost აგზავნის, თემებს, backup-ებსა და განახლებებს, და შეცდომებს, რომლებსაც ყველაზე ხშირად აწყდებიან.

რისგან შედგება Ghost საკუთარ სერვერზე#

Ghost არის Node.js-ის აპლიკაცია. ყველაფერს, რასაც ხედავ - საჯარო საიტს, წევრების პორტალს, რედაქტორს მისამართზე /ghost - ერთი ხანგრძლივად მომუშავე პროცესი ემსახურება, რომელიც ერთ პორტს უსმენს. ნაგულისხმევად ეს პორტი 2368-ია. Ghost-ს არ სჭირდება PHP, ცალკე ვებსერვერი ან cron-ის ამოცანები; ეს არის ერთი პროცესი და მისი ფაილები.

ეს ფაილები ორ ჯგუფად იყოფა, და ამ დაყოფის გაგება ყველაზე სასარგებლოა, სანამ რამეს შეეხები:

• აპლიკაცია - Ghost-ის საკუთარი კოდი და მისი Node.js-ის დამოკიდებულებები. ის ყოველ განახლებაზე იცვლება, და მისი რედაქტირება არასოდეს არ უნდა დაიწყო.
• საქაღალდე `content` - ყველაფერი, რაც შენია. შენი თემები content/themes-ში, ატვირთული სურათები content/images-ში, მარშრუტების ფაილი content/settings-ში, ლოგები content/logs-ში და მონაცემთა ბაზა content/data-ში.

ამას ემატება ერთი კონფიგურაციის ფაილი, config.production.json, რომელიც Ghost-ს ეუბნება მის საჯარო მისამართს, სად არის მისი ბაზა, როგორ გააგზავნოს ფოსტა და რომელ მისამართსა და პორტს უსმინოს.

მესამე ნაწილი მონაცემთა ბაზაა. Ghost-ს შეუძლია MySQL-ის ან SQLite-ის გამოყენება. Ghost-ის საკუთარი დოკუმენტაცია production-ისთვის MySQL 8-ს გირჩევს და SQLite-ს მსუბუქ ვარიანტად თვლის, მაგრამ SQLite ერთი ფაილია content/data-ს შიგნით, ამიტომ პატარა გამოცემის გაშვება და backup-ი მასთან ძალიან მარტივია: არ არსებობს ცალკე სერვერი, რომლის ზომაც უნდა შეარჩიო, დაიცვა და გადაიხადო. ბლოგისთვის, რომელსაც ერთი ან რამდენიმე ავტორი ჰყავს, ეს გონივრული არჩევანია. სად წყვეტს ის გონივრულობას, FAQ-შია აღწერილი.

RE:NODE-ზე Ghost ერთი დაწკაპებით აპლიკაციების ერთ-ერთი ხაზია. სერვერი Ghost-ს პირველივე გაშვებაზე აყენებს და აწყობს, მონაცემებს კი თავად სერვერზე, SQLite-ში ინახავს, ასე რომ ბაზის ყიდვა არ გჭირდება. ყველა ფაილი, რომელსაც ინსტალერი წერს, ჩანს ფაილ მენეჯერში და SFTP-ით, როგორც ნებისმიერ სხვა სერვერზე, ხოლო ცვლილებებს, რომლებსაც თემებსა და კონფიგურაციაში შეიტან, განახლება არ გადაწერს.

რა ზომის სერვერი სჭირდება Ghost-ს#

Ghost-ის საკუთარი მინიმუმი 1 GB მეხსიერებაა. ეს გულწრფელი ციფრია: უმოქმედო Ghost-ის პროცესი კომფორტულად რჩება ამ ზღვარს ქვემოთ, და პირადი ბლოგი დღეში რამდენიმე ათასი ვიზიტით მასზე უპრობლემოდ მუშაობს. მეხსიერებასა და პროცესორს გვერდების ნახვები კი არ ზრდის - Ghost კარგად ქეშირებს და გვერდების უმეტესობა იაფია - არამედ ეს:

• სურათების ატვირთვა. Ghost ყოველი სურათისთვის ადაპტური განლაგებისთვის შემცირებულ ასლებს ქმნის. ზედიზედ ოცი დიდი ფოტოს ატვირთვა ყველაზე მძიმე საქმეა, რასაც Ghost-ის პატარა სერვერი აკეთებს.
• წევრები და newsletter-ები. newsletter-ის დიდ სიაზე გაგზავნა, წევრების CSV-ის იმპორტი და წევრების განყოფილების დახატვა პოსტების მიწოდებაზე მეტი ჯდება.
• აწყობა პირველ გაშვებაზე. დამოკიდებულებების დაყენებასა და აწყობას მუშაობაზე მეტი მეხსიერება სჭირდება. ეს ერთხელ ხდება.

დისკს ძირითადად სურათები იკავებს. თავად აპლიკაცია რამდენიმე ასეულ მეგაბაიტს იკავებს, ტექსტური პოსტები პაწაწინაა, ფოტობლოგი კი იზრდება ატვირთულის ზომით, პლუს იმ შემცირებული ასლებით, რომლებსაც Ghost მათგან ქმნის, ამიტომ დაგეგმე დაახლოებით ორჯერ მეტი, ვიდრე ატვირთავ.

ეს RE:NODE-ის Ghost-ის გეგმებია, თვეში $5-დან. პატარით დაიწყე: უფრო მაღალ ტარიფზე გადასვლა ლიმიტებს უკვე არსებულ სერვერზე ცვლის, და Ghost-ის ხელახლა დაყენება საჭირო არ არის. თუ გინდა ზოგადი ახსნა, რომელი რესურსი თავდება რეალურად პირველი, სტატია Node-ის მეხსიერების ლიმიტების შესახებ პირდაპირ გამოდგება, რადგან Ghost ისეთივე Node-ის პროცესია, როგორც ნებისმიერი სხვა.

პირველი გაშვება და ადმინისტრატორის ანგარიში#

მანქანაზე, რომელსაც თავად მართავ, Ghost ჩვეულებრივ Ghost-CLI-ით ყენდება: ghost install მომზადებულ Linux-სერვერზე აყენებს Node.js-ის დამოკიდებულებებს, MySQL-ის ბაზას, nginx-ს, სერტიფიკატს და systemd-ის სერვისს. ეს კარგი ხელსაწყოა, მაგრამ ვარაუდობს, რომ მთელი მანქანა შენია, ამიტომ ის VDS-ს უხდება და არა პანელის სერვერს.

ერთი დაწკაპებით ხაზზე ნაბიჯები უფრო მოკლეა:

1. შეუკვეთე გეგმა. სერვერი იქმნება, როცა გადახდა გაივლის, ჩვეულებრივ ერთ წუთში.
2. გაუშვი და კონსოლს ადევნე თვალი. პირველი გაშვება Ghost-ს ჩამოტვირთავს და აწყობს, რაც ნებისმიერ შემდეგ გაშვებაზე მეტხანს გრძელდება. დაელოდე, სანამ Ghost შეგატყობინებს, რომ მუშაობს.
3. გახსენი პანელში ნაჩვენები მისამართი და ბოლოში დაუმატე /ghost. /ghost-ზე პირველი შესვლა დაყენების ეკრანია: საიტის სახელი, შენი სახელი, ელფოსტა და პაროლი. ეს ანგარიში მფლობელი ხდება.
4. დომენი დააყენე (შემდეგი განყოფილება), სანამ ვინმეს მოიწვევ ან რამეს გამოაქვეყნებ, რადგან ბმულები და წერილები იმ მისამართს იყენებენ, რომელიც Ghost-ს თავისად მიაჩნია.

დაყენება მაშინვე გააკეთე. სანამ მფლობელი არ არსებობს, მას ის ქმნის, ვინც პირველი მიაღწევს /ghost-ს. ახალ სერვერზე მისამართი ჯერ არავინ იცის, მაგრამ ეს ნაბიჯი მომავალი კვირისთვის გადასადები არ არის.

შემდეგ რედაქციის ანგარიშებია: Ghost-ს აქვს როლები Contributor, Author, Editor და Administrator, და ზუსტად ერთი Owner. ავტორებს რედაქციის პარამეტრებიდან ელფოსტით იწვევ - ეს ნიშნავს, რომ ფოსტა ჯერ უნდა მუშაობდეს, და სწორედ ამიტომ არ არის ქვემოთ ფოსტის განყოფილება არასავალდებულო.

პარამეტრი url და შენი დომენი#

url ის პარამეტრია, რომელიც Ghost-ის საიტებს ყველა სხვაზე ხშირად აფუჭებს. მისგან აგებს Ghost ყოველ ბმულს, canonical ტეგს, RSS-ის ელემენტს, sitemap-ის ჩანაწერს, სურათის მისამართს და წერილის ბმულს, და მასზე გადაამისამართებს სტუმრებს. ეს უნდა იყოს ზუსტი საჯარო მისამართი, სქემის ჩათვლით:

{  "url": "https://blog.example.com",  "server": {    "host": "0.0.0.0",    "port": 2368  }}

იგივე მნიშვნელობები ფაილის ნაცვლად გარემოს ცვლადებიდანაც შეიძლება მოვიდეს. Ghost ჩადგმულ გასაღებებს ორმაგი ქვედა ხაზით კითხულობს, ასე რომ server__port აყენებს server.port-ს, ხოლო mail__transport აყენებს mail.transport-ს:

url=https://blog.example.comserver__host=0.0.0.0server__port=2368

გარემოს ცვლადი ფაილს სჯობს. ეს უნდა გახსოვდეს, როცა config.production.json-ის ცვლილება თითქოს იგნორირებულია: იგივე გასაღებს სხვა რამ აყენებს. პანელის სერვერზე მისამართი და პორტი, რომელსაც Ghost უსმენს, ინსტალაციამ უკვე მოარგო სერვერზე გამოყოფილ პორტს, ამიტომ server.host-სა და server.port-ს ნუ შეეხები, თუ არ იცი, რატომ ცვლი. შენ url-ს ცვლი.

RE:NODE-ზე აპლიკაციების გეგმებს reverse proxy-ის სლოტი აქვს. დაამატე დომენი proxy-ის სლოტში, მისი A ჩანაწერი პანელში ნაჩვენებ მისამართზე მიმართე, და სერტიფიკატი ავტომატურად გაიცემა და განახლდება. შემდეგ url-ში ჩაწერე https:// პლუს ეს დომენი და Ghost გადატვირთე. რიგითობას მნიშვნელობა აქვს: თუ დომენს url-ში DNS-ისა და სერტიფიკატის მზადყოფნამდე ჩაწერ, Ghost ყველა სტუმარს, შენც ჩათვლით, ისეთ მისამართზე გადაამისამართებს, რომელიც ჯერ არ პასუხობს.

დომენის მხარე - A ჩანაწერები, რამდენ ხანს სჭირდება DNS-ს და რა სჭირდება სერტიფიკატს - აღწერილია სტატიაში შენი დომენისა და მისი სერტიფიკატის შესახებ, ხოლო სტატია იმაზე, რას აკეთებს reverse proxy, ხსნის, რატომ არ ეხება აქ თავად Ghost HTTPS-ს არასოდეს. proxy-ის ერთი შედეგი: Ghost ყველა სტუმარს proxy-დან მოსულად ხედავს, კლიენტის ნამდვილი მისამართი კი სათაურში X-Forwarded-For მოდის.

თუ გინდა, რომ example.com-იც და www.example.com-იც მუშაობდეს, ერთი აირჩიე url-ად და მეორე მასზე გადაამისამართე; Ghost ერთ კანონიკურ მისამართზე პასუხობს. რომელი აირჩიო, განხილულია სტატიაში www-ისა და ძირითადი დომენის და გადამისამართებების შესახებ.

ფოსტა: ტრანზაქციული წერილები და newsletter-ები#

Ghost ორ სხვადასხვა სახის წერილს ორი სხვადასხვა გზით აგზავნის, და მათი აღრევა ყველაზე ხშირი მიზეზია, რის გამოც ახალი საიტი ნახევრად გაფუჭებულად გამოიყურება.

ტრანზაქციული ფოსტა ერთი შეტყობინებაა ერთი ადამიანისთვის: რედაქციის მოწვევები, პაროლის აღდგენა და - ყველაზე მნიშვნელოვანი - შესვლის ბმულები, რომლებსაც წევრები იღებენ. Ghost-ის წევრებს პაროლი არ აქვთ; ისინი ელფოსტით გაგზავნილი ბმულით შედიან. თუ ტრანზაქციული ფოსტა არ მუშაობს, ვერავინ დარეგისტრირდება და ვერც შევა, მკითხველის მხრიდან კი პორტალი ჩუმად ვერ მუშაობს. ეს ფოსტა კონფიგურაციის ბლოკ mail-ით გადის, ჩვეულებრივ SMTP-ით:

{  "mail": {    "from": "'Example Blog' <noreply@example.com>",    "transport": "SMTP",    "options": {      "host": "smtp.example.com",      "port": 465,      "secure": true,      "auth": {        "user": "noreply@example.com",        "pass": "your-smtp-password"      }    }  }}

პორტი 465 TLS-ს პირველივე ბაიტიდან იყენებს და secure: true სჭირდება; პორტი 587 დაუშიფრავად იწყება და მერე გადადის დაშიფვრაზე, ამიტომ secure false-ად უნდა დარჩეს. მათი აღრევა გამოსადეგი შეტყობინების ნაცვლად timeout-ს ან TLS-ის შეცდომას იძლევა. მისამართი from ისეთი უნდა იყოს, რომლის სახელითაც SMTP სერვერს გაგზავნის უფლება აქვს, ისეთ დომენზე, რომლის SPF და DKIM ჩანაწერები ამ სერვერს მოიცავს, თორემ ფოსტა სპამში მოხვდება - ჩანაწერები განხილულია სტატიაში რატომ ხვდება წერილები სპამში.

საიდან აიღებ SMTP სერვერს, შენი გადასაწყვეტია: ტრანზაქციული ფოსტის პროვაიდერი, არსებული საფოსტო ყუთის გამავალი სერვერი ან საკუთარი. RE:NODE ყიდის Mail Server-ის ხაზს Stalwart-ით, რომელიც Ghost-ისთვის SMTP სერვერად გამოდგება - ამას აღწერს სტატია Stalwart-ის საფოსტო სერვერის დაყენების შესახებ, ვარიანტებს კი ადარებს სტატია აპლიკაციიდან ტრანზაქციული ფოსტის შესახებ. Ghost-ს მხოლოდ გაგზავნის პორტამდე მისვლა სჭირდება, მაგალითად 587 ან 465; პორტი 25 მას არასოდეს სჭირდება.

newsletter-ები მასობრივი გზაა: ერთი პოსტი ელფოსტით ყველა გამომწერს. newsletter-ებს Ghost SMTP-ით არ აგზავნის. მასობრივი გაგზავნა Mailgun-ით ხდება, რომელიც Ghost-ის ადმინში, newsletter-ის ფოსტის პარამეტრებში, Mailgun-ის დომენითა და API გასაღებით ყენდება და არა config.production.json-ში. მის გარეშე Ghost მაინც აქვეყნებს პოსტებს და წევრებს რეგისტრაციის საშუალებას აძლევს, მაგრამ პოსტის ელფოსტით გაგზავნის ოფცია არ იქნება. newsletter-ის გარეშე ბლოგს Mailgun-ი საერთოდ არ სჭირდება; ბლოგს, რომლის მთელი აზრი newsletter-ია, კი სჭირდება.

თემები და იერსახის მორგება#

Ghost-ის თემა არის საქაღალდე Handlebars-ის შაბლონებით (ფაილები .hbs), CSS-ით, JavaScript-ით და ფაილით package.json, რომელიც თემასა და მის პარამეტრებს აღწერს. ახალ ვერსიებს ნაგულისხმევი თემა მოყვება, ოფიციალური და მარკეტპლეისის თემები კი უფასო ან ფასიანი zip არქივებია.

დაყენების ორი გზა არსებობს:

• ატვირთე zip Ghost-ის ადმინში, დიზაინის პარამეტრებში. Ghost თემას ამოწმებს, ჩამოთვლის შეცდომებსა და გაფრთხილებებს და გაძლევს მისი გააქტიურების საშუალებას. ეს ჩვეულებრივი გზაა.
• დააკოპირე საქაღალდე `content/themes`-ში SFTP-ით ან ფაილ მენეჯერით, შემდეგ Ghost გადატვირთე, რომ ახალი თემა შეამჩნიოს, და ადმინში გაააქტიურე. სასარგებლოა თემისთვის, რომელსაც თავად ავითარებ, ან ისეთისთვის, რომელიც კომფორტულად ასატვირთად ძალიან დიდია.

თემა ასლად შეცვალე, არასოდეს ადგილზე. საქაღალდეს სახელი გადაარქვი (და name მის package.json-ში), რომ ავტორის მიერ თემის განახლებამ შენი ცვლილებები ჩუმად არ ჩაანაცვლოს, და შეცვლილი თემა Git-ში შეინახე ან სულ მცირე zip-ად შენს კომპიუტერზე. ფაილებთან პირდაპირ სამუშაოდ დაკავშირების დეტალები სტატიაშია SFTP-ისა და ფაილ მენეჯერის შესახებ.

content-სა და ადმინში კიდევ ორი რამის ცოდნა ღირს:

• content/settings/routes.yaml URL-ების სტრუქტურას მართავს: საკუთარი კოლექციები, სტატიკური მთავარი გვერდი, ტაქსონომიები. მისი ჩამოტვირთვა და ატვირთვა ადმინიდან შეიძლება. მცდარ მარშრუტების ფაილს შეუძლია საიტის მთელი განყოფილებები 404-ზე გადაიყვანოს, ამიტომ შეცვლამდე წინა ვერსია შეინახე.
• Code injection ადმინში საიტის head-სა და footer-ში ფრაგმენტებს ამატებს - ანალიტიკას, შრიფტს, სტილის პატარა შესწორებას - თემასთან შეხების გარეშე. პატარა ცვლილებებისთვის ის ამჯობინე; ისინი თემის შეცვლას გადაურჩებიან.

თემის დიდი ცვლილებები ცოცხალი საიტის გარდა სხვაგან უფრო ადვილად მოწმდება. სატესტოდ Ghost-ის მეორე პატარა სერვერი ცოტა ჯდება და ამაზე სტატიაა სატესტო სერვერის შესახებ production-ის გვერდით.

backup-ები, რომლებიც ყველაფერს მოიცავს#

Ghost-ის საიტი სამი რამაა: მონაცემთა ბაზა, საქაღალდე content და config.production.json. backup-ი, რომელსაც რომელიმე მათგანი აკლია, სრული არ არის.

SQLite-ის შემთხვევაში ბაზა content/data-ს შიგნით დევს, ამიტომ სრული backup-ი არის content-ის ასლი პლუს კონფიგურაციის ფაილი. პრობლემა თანმიმდევრულობაშია. SQLite-ის ფაილის კოპირებამ, როცა Ghost მასში წერს, შეიძლება ისეთი ასლი შექმნას, რომელიც არ გაიხსნება. უსაფრთხო ვარიანტები, უპირატესობის მიხედვით:

1. გააჩერე Ghost, დააკოპირე ფაილები, ისევ გაუშვი. რამდენიმე წამიანი შეფერხება და გარანტირებულად სუფთა ასლი.
2. გამოიყენე SQLite-ის საკუთარი backup-ის ბრძანება, თუ ხელსაწყო sqlite3 ხელმისაწვდომია; ის ცოცხალი ბაზის თანმიმდევრულ ასლს ქმნის.
3. ასლი წყნარ საათზე გადაიღე და რამდენიმე შეინახე, რომ ერთი ცუდი ასლი ერთადერთი არ აღმოჩნდეს.

$ sqlite3 content/data/ghost.db ".backup 'ghost-backup.db'"$ tar czf ghost-content-$(date +%F).tar.gz content config.production.json

ფაილის სახელი ghost.db ჩვეულებრივია, მაგრამ რამის სკრიპტად გადაქცევამდე შეამოწმე, რა დევს რეალურად content/data-ში.

Ghost-ს პარამეტრებში ექსპორტიც აქვს, რომელიც პოსტებს, გვერდებს, ტეგებსა და პარამეტრებს JSON ფაილად ჩამოტვირთავს, წევრების ექსპორტი კი CSV-ად შეიძლება. ეს სასარგებლოა - JSON-ის ექსპორტით გადაგაქვს კონტენტი Ghost-ის სხვადასხვა ვერსიის ინსტალაციებს შორის - მაგრამ თავისთავად backup-ი არ არის. JSON-ის ექსპორტი სურათებსა და თემებს არ შეიცავს, და მისგან მთელი საიტის აღდგენა ფაილების აღდგენაზე ნელი და დანაკარგიანია.

RE:NODE-ზე Ghost-ის ყველა გეგმას აქვს backup-ის სლოტები: ერთიდან Starter-ზე ოთხამდე Pro-ზე. backup-ის გაკეთება ხელით ან განრიგით შეიძლება, ის ინახება იმ მანქანის გარეთ, რომელსაც იცავს, მისი ჩამოტვირთვა შეიძლება და ღილაკით აღდგება. ჩანართ Schedules-ს შეუძლია ერთ მოწესრიგებულ ამოცანაში სერვერი გააჩეროს, backup-ი გააკეთოს და ისევ გაუშვას - ეს ზემოთ აღწერილი „გაჩერება, კოპირება, გაშვება“ სქემაა, ოღონდ ისე, რომ ვინმეს ამისთვის ღამე ფხიზლად ყოფნა არ სჭირდება. განახლებამდე გაკეთებული backup-ი დაბლოკე, რომ როტაციამ ის არ წაშალოს. სერვერის წაშლა მის backup-ებსაც შლის, დაბლოკილების ჩათვლით, ამიტომ ყველაფრის ჩამოტვირთული ასლი შეინახე, რისი დაკარგვაც გეწყინება. რატომ უნდა აღადგინო ხანდახან backup-ი სატესტოდ, ხსნის სტატია backup-ების შესახებ, რომლებიც მართლა აღდგება, პანელის ნაბიჯები კი backup-ების სახელმძღვანელოშია.

Ghost-ის უსაფრთხო განახლება#

Ghost ხშირად გამოდის. მცირე განახლებები ჩვეულებრივ უმტკივნეულოდ გადის; მთავარი ვერსიები ცვლის იმას, რაზეც თემები და ინტეგრაციები არის დამოკიდებული, და გამოშვების შენიშვნებში წერია, კონკრეტულად რას. მანქანაზე, რომელსაც Ghost-CLI-ით მართავ, ghost update ახალ ვერსიას ჩამოტვირთავს, ბაზის მიგრაციებს უშვებს და გადატვირთავს. როგორ მიიწევს ვერსია წინ ერთი დაწკაპებით სერვერზე, მის ინსტალაციაზეა დამოკიდებული; გაშვებისას კონსოლის გამონატანს ადევნე თვალი და მთავარ განახლებამდე მხარდაჭერას ჰკითხე, თუ დარწმუნებული არ ხარ, რა მოხდება.

რაც არ უნდა ასრულებდეს განახლებას, რიგი ერთი და იგივეა:

1. წაიკითხე გამოშვების შენიშვნები ყოველი მთავარი ვერსიისთვის შენსა და სამიზნეს შორის.
2. შეამოწმე თემა ახალ ვერსიასთან თავსებადობაზე. Ghost-ის თემების ვალიდატორი (იგივე, რომელიც ატვირთვისას ეშვება) აცნობებს შაბლონებსა და helper-ებზე, რომლებიც აღარ არის მხარდაჭერილი. თემა, რომელიც ძველ მთავარ ვერსიაზე მუშაობდა, შეიძლება ახალზე გააქტიურებაზე უარი თქვას.
3. გააკეთე backup-ი გაჩერებული Ghost-ით და ეს backup-ი დაბლოკე.
4. განაახლე და ლოგს ადევნე თვალი, სანამ Ghost ბაზის მიგრაციებს ასრულებს. სერვერი მიგრაციის შუაში არ გააჩერო.
5. გადაიარე საიტი: მთავარი გვერდი, პოსტი, ტეგის გვერდი, წევრების პორტალი, ადმინის რედაქტორი. საკუთარ თავს სატესტო წერილი გაუგზავნე.

თუ განახლება ცუდად წავიდა, backup-ის აღდგენა ფაილებსა და ბაზას ზუსტად მის წინა მდგომარეობაში აბრუნებს - ამიტომაც კეთდება backup-ი განახლებამდე და არა პირველი შეცდომის შემდეგ. ამისთვის ზოგადი ჩვევები აღწერილია სტატიაში პატარა სერვერზე შეფერხების გარეშე deploy-ის შესახებ, თუმცა Ghost-ის ერთ პროცესს მოკლე გადატვირთვა ასეა თუ ისე ექნება.

პრობლემების მოგვარება#

საიტი უსასრულო გადამისამართებაში ვარდება ან სულ არასწორ მისამართზე გაგზავნის. url არ ემთხვევა იმას, როგორ იხსნება საიტი. შეამოწმე სქემა (https თუ http), ჰოსტის სახელი (www-ით თუ მის გარეშე) და რომ ბოლოში ზედმეტი გზა არ დამატებულა. reverse proxy-ის უკან Ghost ასევე ეყრდნობა იმას, რომ proxy სათაურით X-Forwarded-Proto ეუბნება, რომ თავდაპირველი მოთხოვნა HTTPS-ით იყო; თუ ის აკლია, https-იანი url უსასრულო გადამისამართებას იწვევს.

წევრებს შესვლის ბმული არასოდეს მოსდით. ტრანზაქციული ფოსტა დაყენებული არ არის ან ვერ მუშაობს. Ghost-ის ლოგში SMTP-ის შეცდომა მოძებნე. ხშირი მიზეზები: პორტისა და secure-ის არასწორი კომბინაცია, SMTP-ის ანგარიში, რომელსაც from მისამართის სახელით გაგზავნის უფლება არ აქვს, ან წერილი მიდის, მაგრამ სპამში ხვდება, რადგან SPF ან DKIM აკლია.

პოსტის ელფოსტით გაგზავნის ოფცია არ ჩანს. newsletter-ებს ადმინში დაყენებული Mailgun-ი სჭირდებათ. SMTP-ის პარამეტრები მასობრივ გაგზავნას არ რთავს.

დომენის შეცვლის შემდეგ სურათები ან ბმულები ძველ მისამართზე მიუთითებს. შეცვალე url, გადატვირთე, და გენერირებული ბმულები მას მიჰყვება. ცვლილებამდე პოსტებში ჩასმული სურათები ინახება გზებით, რომლებსაც Ghost url-დან გადაწერს, მაგრამ ყველაფერი, რაც თემაში ან code injection-ში მყარად არის ჩაწერილი, ხელით უნდა შეასწორო.

თემის ატვირთვა შეცდომებით მარცხდება. ვალიდატორმა იპოვა შაბლონები ან helper-ები, რომლებსაც გაშვებული Ghost-ის ვერსია არ უჭერს მხარს. წაიკითხე ჩამოთვლილი შეცდომები; მათში ფაილია მითითებული. შეასწორე ისინი თემის შენს ასლში, ან იშოვე თემის ის ვერსია, რომელიც შენი Ghost-ის გამოშვებისთვისაა აგებული.

Ghost დიდი ატვირთვების ან იმპორტის დროს გადაიტვირთება. პროცესმა მეხსიერების ლიმიტს მიაღწია. ერთდროულად ნაკლები სურათი ატვირთე, ფოტოები ატვირთვამდე შეამცირე, ან უფრო მაღალ ტარიფზე გადადი. გადატვირთვების ციკლი, რომელიც არ ჩერდება, განხილულია სტატიაში რატომ იტვირთება სერვერი სულ თავიდან - დიაგნოზი ნებისმიერი პროცესისთვის ერთნაირია.

`config.production.json`-ის ცვლილება არაფერს ცვლის. ან Ghost არ გადატვირთულა (ფაილს მხოლოდ გაშვებისას კითხულობს), ან იგივე გასაღებს გარემოს ცვლადი აყენებს და ის იმარჯვებს.

FAQ#

საკმარისია თუ არა SQLite Ghost-ის ბლოგისთვის?

პირადი ბლოგისთვის ან პატარა გამოცემისთვის - კი: ის სწრაფია, ცალკე სერვერი არ სჭირდება და backup-ი ფაილივით კეთდება. Ghost-ის საკუთარი რეკომენდაცია production-ისთვის MySQL 8-ს ანიჭებს უპირატესობას, და საიტი ბევრი ავტორით, ძალიან დიდი წევრების სიით ან ინტენსიური პარალელური ჩაწერით სწორედ ის შემთხვევაა, როცა MySQL თავის ფასს ამართლებს. მოგვიანებით გადასვლა ნიშნავს კონტენტის ექსპორტს და იმპორტს ახალ ინსტალაციაში, რომელიც MySQL-ზეა მორგებული.

სჭირდება თუ არა Ghost-ის გასაშვებად Mailgun-ი?

მხოლოდ newsletter-ებისთვის. შესვლის ბმულები, რედაქციის მოწვევები და პაროლის აღდგენა ჩვეულებრივი SMTP-ით მიდის. ბლოგი, რომელიც პოსტებს გამომწერებს ელფოსტით არასოდეს უგზავნის, Mailgun-ის გარეშე რამდენ ხანსაც გინდა, ისე იმუშავებს.

შემიძლია საკუთარი დომენის გამოყენება უფასო HTTPS-ით?

კი. დაამატე დომენი proxy-ის სლოტში, A ჩანაწერი სერვერის მისამართზე მიმართე, დაელოდე სერტიფიკატს, შემდეგ url-ში https-იანი მისამართი ჩაწერე და Ghost გადატვირთე. სერტიფიკატი ავტომატურად ახლდება.

რამდენი მეხსიერება სჭირდება Ghost-ის ბლოგს?

პირადი ბლოგისთვის დაახლოებით 1 GB, რაც Ghost-ის საკუთარი მითითებული მინიმუმია. მეტი გამოგადგება დიდი სურათების ატვირთვისას, წევრების დიდი იმპორტისას და newsletter-ების გაგზავნისას. მხოლოდ გვერდების ნახვები უფრო დიდ გეგმას იშვიათად ამართლებს.

გადაწერს თუ არა განახლება ჩემს ცვლილებებს თემაში?

Ghost-ის განახლება აპლიკაციას ცვლის და არა საქაღალდე content-ს, ასე რომ შენი თემები და სურათები რჩება. რისკი სხვაგანაა: თემის ავტორის განახლებამ შეიძლება შენი ცვლილებები გადაწეროს, ამიტომაც შეცვლილ თემას სახელს უცვლიან. ნებისმიერ შემთხვევაში ყოველი განახლების წინ backup-ი გააკეთე.

შემიძლია არსებული Ghost-ის საიტის ახალ სერვერზე გადატანა?

კი. ძველ საიტზე კონტენტის ექსპორტი JSON-ად გააკეთე, დააკოპირე საქაღალდე content/images და შენი თემა, შემდეგ JSON ახალ ინსტალაციაში დააიმპორტე და თემა ატვირთე. წევრების ექსპორტი და იმპორტი CSV-ით ხდება. მთელი საქაღალდე content-ის კოპირებაც მუშაობს, თუ ორივე ინსტალაციაზე Ghost-ის ერთი და იგივე ვერსიაა.