One-click აპები: WordPress, Ghost, Strapi და mail server

One-click აპი გიზოგავს ინსტალაციას და მეტს არაფერს. RE:NODE-ზე ასეთი ოთხი ხაზია: WordPress, სადაც ფაილები თავის ადგილასაა, MySQL ბაზა კი უკვე შექმნილი და მიერთებულია; Ghost, რომელიც სერვერის პირველ გაშვებაზე იდგმება და შენდება, მონაცემები კი SQLite-შია; Strapi, რომელიც ანალოგიურად იქმნება და შენდება, ისიც SQLite-ზე; და Mail Server, სადაც მუშაობს Stalwart SMTP-ით, IMAP-ით, JMAP-ით და web admin-ით. ყველა შემთხვევაში პირველი, რასაც აკეთებ, არის მისამართის გახსნა და admin ანგარიშის დაკავება, ხოლო შენზე დარჩენილი ოთხი რამ ყველა ხაზზე ერთნაირია: დომენი, გამავალი ფოსტა, backup-ები, რომლებიც რეალურად გამოგიცდია, და განახლებები. WordPress აირჩიე საიტისთვის, რომელსაც plugin-ები და ნაცნობი რედაქტორი სჭირდება, Ghost - წერისა და newsletter-ებისთვის, Strapi - როცა ცალკე front end-ს content API სჭირდება, ხოლო Mail Server მხოლოდ მაშინ, თუ ფოსტის თვითონ გაძღოლა გინდა და ამის პირობებს ეთანხმები.

ამ პოსტის დანარჩენი ნაწილი ხაზ-ხაზ გადის: რა არის წინასწარ დაყენებული, როგორ გამოიყურება პირველი შესვლა, რა პარამეტრებს მაინც შეეხები და რომელი შეცდომები უჯდება ადამიანებს პირველ დღეს.

რას აყენებს ოთხი one-click ხაზი#

One-click ხაზი დასრულებული აპლიკაციაა და არა runtime, რომელსაც საკუთარი კოდით ავსებ. სერვერი იქმნება გადახდის დადასტურებისთანავე, ჩვეულებრივ ერთ წუთში, ინსტალაცია კი პირველ გაშვებაზე ხდება (WordPress-ის შემთხვევაში - პირველ ინსტალაციაზე). ამის შემდეგ ის ჩვეულებრივი სერვერია: იგივე კონსოლი, ფაილების მენეჯერი, SFTP, backup-ები და განრიგები, რაც ყველა სხვა გეგმაზე, და არაფერია დონეზე მიბმული.

ამ ხაზებიდან ორს ცალკე ბაზა არ სჭირდება. Ghost და Strapi კონტენტს SQLite ფაილში ინახავენ თვითონ სერვერზე, ამიტომ დასამატებელი ან მისაერთებელი არაფერია; თუ მოგვიანებით PostgreSQL ან MySQL მოგინდება, database ხაზს დაამატებ და აპლიკაციას იქით მიუთითებ. WordPress განსხვავებულია, რადგან WordPress-ს MySQL სჭირდება, ამიტომ WordPress-ის ხაზი თავისთვის ქმნის MySQL ბაზას და კავშირის მონაცემებს wp-config.php-ში წერს. Mail Server-ი საფოსტო ყუთებს საკუთარ დისკზე ინახავს.

ერთი რამ, რაც სიაში არ არის, ისევე მნიშვნელოვანია, როგორც ის, რაც არის. One-click ინსტალაცია მხოლოდ ამ ხაზებზეა. Engines-ის web გეგმებზე, რომლებიც Drupal-ის, Joomla-ს, DLE-ს ან Laravel აპლიკაციისთვისაა გათვლილი, CMS-ს თვითონ აყენებ, ხოლო modpack-ების, plugin-ებისა და თემების installer არსად არსებობს. თვითონ დასაყენებელ ვარიანტებს CMS ჰოსტინგის შედარება განიხილავს.

რა ხდება პირველ გაშვებაზე#

მოვლენების თანმიმდევრობა ოთხივე ხაზზე ერთნაირია და მისი ცოდნა support-ის ბილეთს გიზოგავს.

1. სერვერი პანელში ჩნდება. მას აქვს მისამართი და პორტი, რომლებიც სერვერის გვერდის თავში ჩანს.
2. გაუშვი და Console ჩანართი ღია დატოვე. Ghost და Strapi ამ პირველ გაშვებაზე იწერებიან და შენდებიან, რაც შესამჩნევად უფრო დიდხანს გრძელდება, ვიდრე ნებისმიერი შემდგომი გაშვება, და კონსოლი ყველა ნაბიჯს აჩვენებს. build ასევე ყველაზე მეტ მეხსიერებას ითხოვს ამ აპლიკაციების ყველა მოქმედებას შორის, ამიტომ პირველი გაშვება სწორედ ის მომენტია, როცა მეხსიერების გრაფიკს უნდა უყურო.
3. როცა კონსოლი იტყვის, რომ აპლიკაცია უსმენს, გახსენი მისამართი. თითოეულ ხაზს თავისი პირველი ეკრანი აქვს, ქვემოთაა აღწერილი.
4. admin ანგარიში დაუყოვნებლივ დაიკავე. WordPress-ზე, Ghost-სა და Strapi-ზე setup ეკრანამდე პირველად მისული ადამიანი ხდება მფლობელი. ახალი სერვერის მისამართი ჯერ არავინ იცის, მაგრამ ეს ის ნაბიჯი არ არის, რომელიც ხვალისთვის უნდა გადადო.
5. მხოლოდ ამის მერე მიუთითე დომენი.

თუ პირველი გაშვება listening შეტყობინების ნაცვლად შეცდომით მთავრდება, გადატვირთვამდე წაიკითხე კონსოლის ბოლო ოცდაათი ხაზი. გადატვირთვა იმავე ნაბიჯს იმეორებს და ჩვეულებრივ ისევ იმავე წერტილში ვარდება. ორი მიზეზი, რომელსაც ყველაზე ხშირად ვხედავთ: build-ს მეხსიერება არ ჰყოფნის გეგმაზე, რომელიც მომსახურებისთვისაა გათვლილი და არა build-ისთვის, და ფაილი, რომელიც მომხმარებელმა შეცვალა პირველი გაშვების დასრულებამდე.

WordPress: პირველი შესვლა და რა არის უკვე გაკეთებული#

WordPress-ის ხაზზე პირველი ინსტალაცია WordPress-ს web root-ში ჩამოტვირთავს, მისთვის MySQL ბაზას შექმნის გენერირებული მომხმარებლითა და პაროლით და ამ მონაცემებს wp-config.php-ში ჩაწერს. ანუ WordPress-ის ინსტალაციის ის ნაწილი, რომელიც ჩვეულებრივ ტყდება - ბაზის შექმნა, მისი host-ის, მომხმარებლისა და პაროლის კონფიგურაციაში ხელით ჩაწერა - უკვე დასრულებულია. WordPress-ის ხელით ინსტალაცია გვიჩვენებს, როგორ გამოიყურება ეს ნაბიჯი, როცა მას შენ მაგივრად არავინ აკეთებს.

სერვერის მისამართზე პირველი ვიზიტისას იხსნება WordPress-ის installer. ის ხუთ რამეს ითხოვს: საიტის სათაურს, admin-ის სახელს, პაროლს, ელფოსტის მისამართს და იმას, უნდა დააინდექსოს თუ არა საძიებო სისტემებმა საიტი. admin-ის სახელად admin არ აირჩიო, გამოიყენე გრძელი გენერირებული პაროლი და მიუთითე ელფოსტა, რომელსაც კითხულობ, რადგან პაროლის აღდგენა იქ მოდის. თუ საიტი ჯერ მზად არ არის, მონიშნე ველი, რომელიც საძიებო სისტემებს აჩერებს; ის noindex სიგნალს ამატებს, რომლის მოხსნაც გაშვებისას უნდა გახსოვდეს: Settings, Reading.

რაც ღირს, რომ შეამოწმო wp-config.php-ში ფაილების მენეჯერიდან, როცა შიგნით შეხვალ:

// Database details are already written by the install - leave them.// Check the eight keys and salts are long random strings, not placeholders.define( 'AUTH_KEY', '...' );// Useful additions for a production site:define( 'DISALLOW_FILE_EDIT', true );   // no theme/plugin editor in wp-admindefine( 'WP_POST_REVISIONS', 10 );      // cap stored revisions per postdefine( 'WP_DEBUG', false );

თუ რომელიმე key და salt ჯერ კიდევ put your unique phrase here-ს წერს, შეცვალე ისინი WordPress-ის საკუთარი გენერატორის მნიშვნელობებით მისამართზე https://api.wordpress.org/secret-key/1.1/salt/. მათი შეცვლა ყველას სისტემიდან გამოაგდებს, რაც ახალ საიტზე უვნებელია.

რას აკონფიგურირებ WordPress-ზე მაინც:

• მისამართი. WordPress საკუთარ URL-ს ბაზაში ინახავს (Settings, General: WordPress Address და Site Address). როცა შენი დომენი და სერტიფიკატი იმუშავებს, ორივე შეცვალე https:// პლუს დომენით. გააკეთე ეს მას შემდეგ, რაც HTTPS პასუხობს და არა მანამდე, თორემ wp-admin-ს გარეთ დარჩები: redirect მისამართზე გადაგიყვანს, რომელიც ჯერ არ არსებობს.
• Permalinks. Settings, Permalinks, შემდეგ აირჩიე "Post name". WordPress-ის ხაზი web-hosting stack-ზე მუშაობს, ანუ nginx-სა და PHP-ზე, ამიტომ .htaccess წესები, რომლებსაც plugin-ები წერენ, არაფერს აკეთებენ. Plugin-ები, რომლებიც პრობლემების .htaccess-ით გასწორებას გპირდებიან, აქ არასწორი ინსტრუმენტია.
• გამავალი ფოსტა. WordPress ნაგულისხმევად PHP-ის mail()-ით აგზავნის, რაც ნებისმიერი სერვერიდან ფოსტის გაგზავნის ყველაზე არასანდო გზაა. დააყენე SMTP plugin და მიუთითე რეალურ საფოსტო სერვისზე. ვარიანტებს ტრანზაქციული ელფოსტა შენი აპიდან განმარტავს.
• Caching. ახალი WordPress ყოველი მოთხოვნისას ყველა გვერდს PHP-ით აგენერირებს. page cache ყველაზე დიდი ცვლილებაა სიჩქარეში, რისი გაკეთებაც შეგიძლია; WordPress-ის caching განმარტავს, რა ამცირებს რეალურად time to first byte-ს და რა - არა.
• დაცვის გაძლიერება. plugin-ების განახლებები, login-ის rate limit, გამოუყენებელი plugin-ების წაშლა. სრული სია არის WordPress-ის უსაფრთხოების გაძლიერებაში.

ბაზა ხელმისაწვდომია პანელის database გვერდიდან, სადაც "Open in phpMyAdmin" ერთჯერადი token-ით გაგიშვებს შიგნით. სწორედ აქ გაასწორებ არასწორ siteurl-ს, თუ მაინც გარეთ დარჩები: wp_options ცხრილი, siteurl და home ჩანაწერები.

Ghost: პირველი შესვლა და რას აყენებ შენ#

Ghost სერვერის პირველ გაშვებაზე იდგმება და შენდება, მონაცემები კი SQLite-შია სერვერზევე. შენს საკუთარ მანქანაზე Ghost ჩვეულებრივ Ghost-CLI-ით იდგმება, რომელიც ასევე აყენებს MySQL-ს, nginx-ს, სერტიფიკატსა და service manager-ს; აქ არცერთი ეს არ მოქმედებს, რადგან პროცესების მეთვალყურეობას პანელი უზრუნველყოფს, HTTPS-ს კი proxy slot.

პირველი შესვლა სერვერის მისამართზეა, ბოლოში /ghost-ით. პირველი ვიზიტი setup ეკრანია: საიტის სათაური, შენი სახელი, ელფოსტა და პაროლი. ეს ანგარიში ხდება Owner და Owner მხოლოდ ერთია. თანამშრომლების ანგარიშები მოგვიანებით მოდის მოსაწვევით, Contributor, Author, Editor და Administrator როლებით.

ორი პარამეტრი წყვეტს, იმუშავებს თუ არა Ghost-ის საიტი საჯაროდ, და ორივე ფაილების მენეჯერში config.production.json-შია:

{  "url": "https://blog.example.com",  "mail": {    "transport": "SMTP",    "options": {      "host": "smtp.example.com",      "port": 465,      "secure": true,      "auth": { "user": "postmaster@example.com", "pass": "app-password" }    }  }}

url ზუსტი საჯარო მისამართია, scheme-ის ჩათვლით. Ghost მისგან აგებს ყველა ბმულს, canonical tag-ს, RSS ჩანაწერს, sitemap ჩანაწერს და ელფოსტის ბმულს და სტუმრებსაც მისკენ გადაამისამართებს, ამიტომ დააყენე ის მხოლოდ მას შემდეგ, რაც შენი დომენი HTTPS-ით პასუხობს, და მერე გადატვირთე. server.host და server.port ისე დატოვე, როგორც ინსტალაციამ ჩაწერა: ისინი შეთანხმებულია შენს სერვერზე გამოყოფილ პორტთან.

mail ბლოკი ტრანზაქციული ფოსტისთვისაა: თანამშრომლების მოსაწვევები, პაროლის აღდგენა და წევრების შესვლის ბმულები. მის გარეშე ვერავინ, ვისაც იწვევ, ვერ დაეთანხმება. მასობრივი newsletter-ები Ghost-ის admin-ში ცალკე პარამეტრია; self-hosted Ghost მათ Mailgun-ით აგზავნის, ამიტომ საიტს, რომელსაც წევრებისთვის ელფოსტის გაგზავნა უნდა, ზემოთ აღწერილი SMTP პარამეტრების გარდა Mailgun-ის ანგარიშიც სჭირდება. ამაზე დაგეგმვამდე შეამოწმე Ghost-ის მიმდინარე დოკუმენტაცია, რადგან ეს ისეთი დეტალია, რომელიც major ვერსიებს შორის იცვლება.

თემები admin-იდან zip ფაილებად იტვირთება (Settings, Design), საკუთარი თემები კი SFTP-ით content/themes-შიც შეიძლება ჩაიდოს. ყველაფერი, რაც შენია - სურათები, თემები, SQLite ბაზა - content-ის ქვეშაა. Ghost-ის ჰოსტინგის გზამკვლევი გაცილებით ღრმად განიხილავს newsletter-ებს, თემებს, SQLite-ის backup-ებს და განახლებებს, რომლებიც საიტს არ ამტვრევს.

Strapi: პირველი შესვლა და development რეჟიმის საკითხი#

Strapi-ის ხაზი პირველ გაშვებაზე ქმნის Strapi პროექტს და აგებს მის admin პანელს, კონტენტი კი SQLite-შია. გეგმები იწყება 2 GB მეხსიერებით, რასაც Strapi-ის საკუთარი დოკუმენტაცია ითხოვს admin-ის კომფორტულად ასაგებად; მუშაობისას პროცესი გაცილებით ნაკლებს იყენებს.

პირველი შესვლა სერვერის მისამართზე /admin-ია. პირველ ვიზიტზე გთხოვენ super admin-ის რეგისტრაციას: სახელი, ელფოსტა და პაროლი. Ghost-ის მსგავსად, ინსტალაციის მფლობელი ის არის, ვინც პირველი მივა, ამიტომ პირველი გაშვების შემდეგ დაუყოვნებლივ გააკეთე.

პროექტის საქაღალდეში არის .env ფაილი იმ საიდუმლოებით, რაც Strapi-ს სჭირდება. Strapi-ის საკუთარი გენერატორით შექმნილ პროექტში თითოეულს შემთხვევითი მნიშვნელობა აქვს:

APP_KEYS=...API_TOKEN_SALT=...ADMIN_JWT_SECRET=...TRANSFER_TOKEN_SALT=...JWT_SECRET=...

ეს მნიშვნელობები ახლავე გადაიტანე პაროლების მენეჯერში. გაშვების შემდეგ ისინი არასოდეს უნდა შეიცვალოს: თუ API_TOKEN_SALT-ს თავიდან დააგენერირებ, ყველა API token, რომელიც შენს front end-ს უჭირავს, შეწყვეტს მუშაობას; თუ ADMIN_JWT_SECRET-ს დააგენერირებ, ყველა რედაქტორი სისტემიდან გამოვა. თუ ოდესმე სერვერს თავიდან ააგებ, აღადგინე ზუსტად იგივე ნაკრები.

საკითხი, რომელიც პირველსავე დღეს უნდა გადაწყვიტო, არის ის, სად ქმნი content type-ებს. Strapi-ის Content-Type Builder - სადაც collection type-ებს, ველებსა და კომპონენტებს ქმნი - ცვლილებებს მხოლოდ მაშინ იღებს, როცა Strapi development რეჟიმში მუშაობს. production რეჟიმში (strapi start) ის მხოლოდ წასაკითხია და ეს განზრახ არის ასე, რადგან content type კოდია: ის ფაილებს src/api-ში წერს და ისინი version control-ში უნდა იყოს. Startup ჩანართზე ნახე გაშვების ბრძანება, რომ გაიგო, რომელ რეჟიმში მუშაობს შენი სერვერი. ორი გონივრული სამუშაო პროცესია:

1. კონტენტი მოდელირე შენს მანქანაზე npm run develop-ით, პროექტი GitHub-ზე commit-ით ატვირთე და სერვერზე ჩამოიტანე ან შეცვლილი src საქაღალდის ატვირთვით, ან პანელის GitHub deploy-ით. შემდეგ admin თავიდან ააგე და გადატვირთე.
2. პატარა, ერთი ადამიანის პროექტისთვის მოდელირე პირდაპირ სერვერზე, სანამ ის development რეჟიმში მუშაობს, და საიტის საჯაროდ გახსნამდე production-ზე გადართე. უფრო მარტივია, მაგრამ იმის ისტორია არ რჩება, რა შეცვალე.

რას აკონფიგურირებ Strapi-ზე მაინც: საჯარო url config/server.js-ში, რომ ბმულები და admin შენი დომენის უკან იმუშაოს; API უფლებები Settings, Users and Permissions-ში, რადგან ნაგულისხმევად public როლს არაფრის წაკითხვა არ შეუძლია და "Strapi აბრუნებს 403-ს" ყველაზე ხშირად სწორედ ამიტომ ისმის; API token-ები შენი front end-ისთვის; და upload provider, თუ მედიას public/uploads-ის გარდა სხვაგან ინახავ. Strapi-ის production გზამკვლევი ყველა მათგანს ზუსტი ფაილებით ფარავს.

Mail Server ხაზი: Stalwart და ის, რაც შენზე რჩება#

Mail Server ხაზი მთლიანი Stalwart სერვერია, რომელსაც შენ მართავ, და არა ცალ-ცალკე გაყიდული საფოსტო ყუთები. ის SMTP-ით აგზავნის და იღებს ფოსტას, IMAP-სა და JMAP-ს საფოსტო კლიენტებისთვის იყენებს და აქვს web admin, სადაც დომენებსა და ანგარიშებს ქმნი, DKIM გასაღებებს იღებ და spam ფილტრაციას აწყობ. გეგმებს ხუთი პორტი აქვს, რაც ფარავს submission-ს, IMAPS-ს, web admin-ს და კიდევ რამდენიმეს.

ახალი Stalwart ინსტალაცია იწყება იმ რეჟიმში, რასაც პროექტი bootstrap mode-ს უწოდებს: ის კონსოლში ერთხელ ბეჭდავს დროებით administrator-ის პაროლს, web admin-ის setup კი ითხოვს host name-ს, ნაგულისხმევ დომენს და იმას, სად შეინახოს მონაცემები. ამიტომ პირველი შესვლა Console ჩანართზე იწყება - წაიკითხე პაროლი პირველი გაშვების გამოტანიდან, შედი და შეცვალე ისეთით, რომელიც პაროლების მენეჯერში ინახება. ეს admin ანგარიში ყველა საფოსტო ყუთს კითხულობს და ყველა დომენის ფოსტას გადამისამართებს, ამიტომ საფოსტო ყუთად ნუ გამოიყენებ. Stalwart mail server-ის დაყენება პირველ საათს დეტალურად გადის.

სამი რამ შენზე რჩება და არცერთი არ არის არჩევითი:

example.com.                 MX   10 mail.example.com.mail.example.com.            A    <server address>example.com.                 TXT  "v=spf1 mx -all"<selector>._domainkey        TXT  "v=DKIM1; k=rsa; p=..."_dmarc.example.com.          TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

selector და თვითონ DKIM გასაღები ისაა, რასაც web admin შენი დომენისთვის აჩვენებს; გადაწერე ზუსტად.

• DNS ჩანაწერები. MX, SPF, DKIM და DMARC იმას უნდა გამოუქვეყნო, ვინც შენს DNS-ს მართავს. ჩვენთან zone editor არ არის. DKIM ჩანაწერი web admin-იდან მოდის. რას აკეთებს თითოეული, SPF, DKIM და DMARC განმარტებაშია.
• შემომავალი პორტი 25. სხვა mail server-ები მხოლოდ 25 პორტზე აწვდიან ფოსტას, container კი ამ პორტს საჯარო მისამართზე თავისით ვერ ხსნის. გახსენი ბილეთი და support გადმოგიგდებს მას შენს სერვერზე. ეს ნიშნავს ერთ mail server-ს მისამართზე, რადგან IP-ზე 25-ე პორტის მფლობელი მხოლოდ ერთი სერვერი შეიძლება იყოს.
• გამავალი მიწოდება. თუ ქსელი, სადაც ადრესატის სერვერი დგას, შენგან ფოსტას არ იღებს, ან გამავალი 25 პორტი დაბლოკილია, გააგზავნე relay-ით, რომელსაც web admin-ში აყენებ. როგორ, განმარტავს SMTP relay გამავალი ფოსტისთვის.

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

დომენები და HTTPS ყველა ხაზზე#

დომენის ნაბიჯი web და app ხაზებზე ერთნაირია. თითოეულ გეგმაში შედის reverse-proxy slot. დაამატე შენი დომენი proxy slot-ში, მიუთითე A ჩანაწერი მისთვის იმ მისამართზე, რომელსაც პანელი აჩვენებს, და სერტიფიკატი გაიცემა, შემდეგ კი ავტომატურად განახლდება ვადის გასვლამდე 21-დღიან ფანჯარაში. სტუმრის რეალური IP მისამართი აპლიკაციამდე X-Forwarded-For header-ში მიდის, რაც მნიშვნელოვანია კომენტარების spam ფილტრებისთვის, rate limit-ისთვის და ანალიტიკისთვის.

თანმიმდევრობა, რომელიც გარეთ დარჩენას გვერდს აუვლის, ყველგან ერთნაირია:

1. setup ეკრანი დაასრულე უბრალო სერვერის მისამართზე.
2. დაამატე დომენი proxy slot-ში და შექმენი A ჩანაწერი. მოლოდინის ნაწილს შენი დომენი და მისი სერტიფიკატი განმარტავს.
3. გახსენი https:// პლუს დომენი და დარწმუნდი, რომ სერტიფიკატი სწორია.
4. მხოლოდ ამის მერე შეცვალე თვითონ აპლიკაციის მისამართი: WordPress Address და Site Address, Ghost-ის url, Strapi-ის url.
5. გადატვირთე აპლიკაცია და შეამოწმე, admin ისევ იტვირთება თუ არა.

აპლიკაცია proxy-ს უკან, რომელიც HTTPS-ს ამთავრებს, proxy-სგან უბრალო HTTP-ს ხედავს. Ghost და Strapi ამას url პარამეტრით უმკლავდებიან. WordPress ზოგჯერ ვერ უმკლავდება, რაც მე-4 ნაბიჯის შემდეგ redirect loop-ად ან mixed-content გაფრთხილებებად ჩანს. ჩვეულებრივი გამოსწორება, თუ proxy X-Forwarded-Proto header-ს აგზავნის, არის WordPress-ს ამის შესახებ wp-config.php-ის დასაწყისთან ახლოს ეცნობოს:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {    $_SERVER['HTTPS'] = 'on';}

Mail Server გამონაკლისია: საფოსტო კლიენტები proxy slot-ში არ გადიან, სხვა mail server-ები კი იმ host name-ს ეძებენ, რომელიც შენს MX ჩანაწერშია.

Backup-ები და განახლებები#

ყველა one-click გეგმას აქვს backup slot-ები. backup იღება მოთხოვნისას ან განრიგით, ინახება იმ მანქანის გარეთ, რომელსაც იცავს, ჩამოიტვირთება და ღილაკით აღდგება; ჩაკეტე ისინი, რომლებიც ბრუნვის გარეთ უნდა დარჩეს. ცალკე, ჩვენ ყველა სერვერს ღამით სისტემურ backup-ს ვუღებთ შენი slot-ების გარეთ, მაგრამ მისგან თვითონ ვერ აღდგები - ეს support-ით გადის - ამიტომ შენი საკუთარი backup-ები ჩათვალე იმად, რაც მართლა მნიშვნელოვანია.

რა უნდა იყოს backup-ში, ხაზების მიხედვით განსხვავდება:

WordPress-ის სტრიქონია ის, რომელშიც ადამიანები ყველაზე ხშირად ცდებიან. პოსტები, გვერდები, მომხმარებლები და პარამეტრები MySQL-შია და არა ფაილებში, ამიტომ web root-ის სერვერული backup ნახევარი backup-ია. ბაზაც ამოიღე dump-ით; ბრძანებები არის mysqldump backup-სა და აღდგენაში, პატარა საიტისთვის კი იგივეს აკეთებს phpMyAdmin-ის export.

Ghost-ისა და Strapi-ისთვის SQLite ფაილი თვითონ ბაზაა. მისი კოპირებისას, როცა აპლიკაცია წერს, შეიძლება ფაილი მიიღო, რომელიც აღარ იხსნება. უსაფრთხო სქემაა: გაჩერება, backup, გაშვება, და Schedules ჩანართს ზუსტად ეს შეუძლია ერთ მიმდევრობით დავალებაში მშვიდ საათზე: power action გასაჩერებლად, backup, power action გასაშვებად. ის, რაც ამის შემდეგ მოდის, Backup-ები, რომლებიც მართლა აღდგება-შია: backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა.

განახლებებს შენ აკეთებ. ყველა ფაილი, რომელიც installer-მა ჩაწერა, ფაილების მენეჯერსა და SFTP-ში ჩანს, და რასაც შენ შეცვლი, ჩვენი მხრიდან არ გადაიწერება. WordPress wp-admin-იდან თავისით განახლდება, plugin-ების ჩათვლით; ჯერ backup აიღე. Ghost-ისა და Strapi-ის განახლებები ვერსიის გაზრდაა ბაზის მიგრაციებით, რომლებიც შემდეგ გაშვებაზე სრულდება, ამიტომ წაიკითხე release notes, აიღე backup, განაახლე და პირველი გაშვების ლოგს უყურე. Stalwart ყოველ release-ზე აქვეყნებს განახლების შენიშვნებს; major ვერსიის წინ წაიკითხე.

რომელი აირჩიო#

არჩევანს ძირითადად ის განსაზღვრავს, რას აგებ, და არა ფასის სხვაობა.

რამდენიმე წესი ოთხივეს გაძღოლის გამოცდილებიდან:

• WordPress უსაფრთხო პასუხია ბიზნეს საიტისთვის, რომელიც გვერდითა მიმართულებით გაიზრდება: მაღაზია, დაჯავშნის ფორმა, წევრების ზონა, page builder, რომელსაც ვიღაცის მარკეტინგის გუნდი მოითხოვს. ფასი არის მოვლა - plugin-ები თავდასხმის ზედაპირი და ნელი ნაწილია. გეგმის ზომის შესარჩევად გამოგადგება რამდენი RAM სჭირდება WordPress-ს; Starter დონე ბლოგისთვის ან პატარა ბიზნეს საიტისთვისაა და არა WooCommerce-ისთვის კატალოგით.
• Ghost უკეთესი ინსტრუმენტია, როცა საიტი უმეტესად წერაა. ის caching plugin-ის გარეშეც სწრაფია, წევრები და newsletter-ები ჩაშენებული აქვს და ბევრად ნაკლები მოძრავი ნაწილი აქვს. ის არასწორი ინსტრუმენტია, თუ გჭირდება მაღაზია, ფორუმი ან თვითნებური გვერდის განლაგება.
• Strapi აზრიანია მხოლოდ მაშინ, თუ ვინმე front end-ს აკეთებს: Next.js საიტს, მობილურ აპს, სტატიკური საიტის გენერატორს. დამოუკიდებლად ის JSON-ს გასცემს და არა გვერდებს. თუ პროექტზე არავინ წერს front-end კოდს, აირჩიე Ghost ან WordPress.
• Mail Server იმათთვისაა, ვისაც სურს, რომ დომენის ფოსტა თავისი კონტროლის ქვეშ მყოფ სერვერზე იყოს და მზად არის, უპატრონოს DNS ჩანაწერებს, რეპუტაციას და spam-ს. საკონტაქტო ფორმის შეტყობინებებისთვის relay ან ტრანზაქციული სერვისი საკმარისია.

თუ არცერთი არ ჯდება, ეს არის შემთხვევა app hosting runtime-ისთვის შენი საკუთარი კოდით, ან Engines web გეგმებისთვის CMS-ისთვის, რომელსაც თვითონ აყენებ.

ხშირი პრობლემები პირველ დღეს#

• "502" ან მისამართზე არაფერია პირველ გაშვებაზე. ინსტალაცია ჯერ მიმდინარეობს. Ghost და Strapi პირველ გაშვებაზე შენდებიან; დაელოდე, სანამ კონსოლი იტყვის, რომ აპი უსმენს.
• პირველი გაშვება შეწყდა და თავიდან გაეშვა. მეხსიერების ლიმიტზე kernel container-ს აჩერებს და ის სუფთად გადაიტვირთება swap-ის გამოყენების ნაცვლად. build, რომელსაც გეგმაზე მეტი მეხსიერება სჭირდება, ციკლში ჩავარდება. შეამოწმე მეხსიერების გრაფიკი; გამოსავალი უფრო დიდი დონეა, ხოლო გეგმის შეცვლა სერვერს თავიდან არ აგებს.
• wp-admin-ს გარეთ დარჩი მისამართის შეცვლის შემდეგ. გაასწორე siteurl და home wp_options-ში phpMyAdmin-ით, ან დაამატე define( 'WP_HOME', '...' ); და define( 'WP_SITEURL', '...' ); wp-config.php-ში მათ გადასაფარად.
• Ghost-ის მოსაწვევები არ მიდის. mail ბლოკი არ არის ან არასწორია. გაასწორე, გადატვირთე, მოსაწვევი თავიდან გააგზავნე.
• Strapi ყველა API გამოძახებაზე 403-ს აბრუნებს. Public როლს უფლებები არ აქვს, სანამ find და findOne იმ content type-ებზე არ მიანიჭებ, რომლებიც საჯარო უნდა იყოს, ან API token-ს არ გაგზავნი.
• Strapi-ის content type-ები არ რედაქტირდება. ის production რეჟიმში მუშაობს, რაც განზრახ არის ასე. მოდელირე development რეჟიმში, როგორც ზემოთ წერია.
• ფოსტა არავის inbox-ში არ ხვდება. 25-ე პორტი ჯერ არ არის გადმოგდებული, ან MX ჩანაწერი სხვაგან მიუთითებს. MX შეამოწმე dig MX example.com-ით და პორტისთვის გახსენი ბილეთი.

FAQ#

Ghost-სა და Strapi-ს database გეგმა სჭირდებათ?

არა. ორივე მონაცემებს SQLite-ში ინახავს სერვერზე, ამიტომ დასამატებელი არაფერია. თუ Strapi პროექტს რამდენიმე რედაქტორი და დიდი ტრაფიკი გაუჩნდება, ან გინდა ბაზის point-in-time backup-ები, დაამატე PostgreSQL ხაზი და კონტენტი Strapi-ის საკუთარი export-ითა და import-ით გადაიტანე.

შემიძლია plugin-ებისა და თემების დაყენება one-click ხაზებზე?

კი. WordPress-ზე ნებისმიერ plugin-ს ან თემას აყენებ wp-admin-იდან ან SFTP-ით ტვირთავ. Ghost-ის თემები zip ფაილებად იტვირთება; Strapi-ის plugin-ები npm პაკეტებია, რომლებიც პროექტს ემატება და მერე admin-ს თავიდან აგებ. არაფერი არ არის whitelist-ში.

admin ანგარიშს ჩემთვის ქმნიან?

არა, და ეს განზრახ არის ასე. WordPress, Ghost და Strapi თითოეული პირველ ვიზიტზე setup ეკრანს აჩვენებს და მფლობელის ანგარიშს იქ ქმნი. Mail Server პირველ გაშვებაზე კონსოლში დროებით administrator-ის პაროლს ბეჭდავს, რომელსაც შენ ცვლი.

შემიძლია არსებული საიტის გადმოტანა one-click სერვერზე?

კი, აპლიკაციის საკუთარი ინსტრუმენტებით. WordPress ფაილებისა და ბაზის dump-ის სახით გადადის, WordPress-ის ახალ ჰოსტზე გადატანა კი ამას ეტაპობრივად გადის. Ghost-ს admin-ში აქვს export და import, Strapi-ს კი strapi export და strapi import. ფოსტის გადატანა ცალკე საქმეა.

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

არა. ყველა ფაილი, რომელიც installer-მა ჩაწერა, შენია, ფაილების მენეჯერსა და SFTP-ში, და განახლება შენს შეცვლილს არასოდეს გადაწერს. აპლიკაციის განახლებებს შენ აკეთებ, ამიტომ ყოველის წინ backup აიღე.

შემიძლია WordPress-ისა და mail server-ის ერთ გეგმაზე გაშვება?

არა. თითოეული ხაზი ცალკე სერვერია საკუთარი მისამართითა და პორტებით. WordPress-ი გაუშვი WordPress-ის ხაზზე, ფოსტა - Mail Server ხაზზე, და mail server გამოიყენე WordPress-ის გამავალი ფოსტის SMTP host-ად.