Starter template-ები: პირველი აპი ახალ სერვერზე 5 წუთში

ახალ სერვერზე მომუშავე აპამდე ყველაზე სწრაფი გზა ის არ არის, რომ აპი ჯერ თავად დაწერო. სჯობს დაიწყო პატარა რეპოზიტორიით, რომელიც უკვე აკეთებს იმ ოთხ რამეს, რასაც ჰოსტინგის სერვერი მოითხოვს: უსმენს 0.0.0.0-ზე იმ პორტზე, რომელიც მას მისცეს, აქვს start სკრიპტი ან entry ფაილი, რომელსაც runtime იპოვის, აფიქსირებს runtime-ის ვერსიას, რომელსაც სერვერი გვთავაზობს, და საიდუმლოებებს Git-ს არ აკარებს. შემდეგ ამ რეპოზიტორიას commit-ით commit-ზე შენს აპად აქცევ. შექმენი რეპოზიტორია template-იდან, მიუთითე სერვერს, დააჭირე deploy-ს და პირველი გაშვებისას stack trace-ის ნაცვლად მუშა გვერდს ნახავ. ყველაფერი დანარჩენი ჩვეულებრივი დეველოპმენტია: აკეთებ push-ს, სერვერი იღებს ცვლილებას და თავად რესტარტდება.

ამ პოსტში ვწერთ, რა არის starter template და რით განსხვავდება ის გვერდისგან, რომელსაც ახალი სერვერი თავიდან აჩვენებს; რა ოთხ წესს მისდევს ყველა starter და რატომ; როგორ მივიდეთ ცარიელი სერვერიდან ცოცხალ აპამდე ნაბიჯ-ნაბიჯ; რა დევს ჩვენს ექვს starter-ში (Next.js, Express, Discord bot, Telegram bot, FastAPI და სტატიკური საიტი); როგორ მოვარგოთ ისინი deploy-ის გაფუჭების გარეშე და როგორ ჩავრთოთ deploy ყოველ push-ზე. უმეტესობა მუშაობს ნებისმიერ ჰოსტზე, რომელიც Git-იდან დეპლოიებს; RE:NODE-ის სპეციფიკური ნაწილები ცალკე არის აღნიშნული.

Template, starter page, one-click app: სამი განსხვავებული რამ#

"Starter"-ს ხალხი რამდენიმე რამეზე ამბობს და პირველ დღეს დაბნეულობის უმეტესობა სწორედ აქედან მოდის.

GitHub template repository ჩვეულებრივი რეპოზიტორიაა, რომლის პარამეტრებშიც ერთი უჯრაა მონიშნული. მისი fork-ის ნაცვლად აჭერ Use this template-ს და GitHub შენს ანგარიშში ქმნის სრულიად ახალ რეპოზიტორიას იგივე ფაილებით და სუფთა ისტორიით. ორიგინალთან კავშირი არ რჩება, სინქრონში შესანახი upstream არ არსებობს და შენს commit-ებს სხვა ვერავინ ხედავს. პირველივე წამიდან ის შენია. starter-ისთვის სწორედ ეს ფორმაა საჭირო: template-ში წვლილს არ შეგაქვს, მას ჩონჩხად იღებ.

Starter page არის ის, რასაც ახალი, ცარიელი runtime სერვერი აჩვენებს, სანამ რამეს დაადეპლოებ. RE:NODE-ზე Node.js-ის გარდა ყველა runtime ხაზი თავის მისამართზე პატარა მუშა გვერდით იწყებს, სანამ კოდს არ დაადეპლოებ, და ეს გვერდი შენს ფაილებს არასოდეს ანაცვლებს. ის იმისთვისაა, რომ ახალი სერვერის პირველმა გაშვებამ Cannot find module './index.js'-ით ჩამოვარდნის ნაცვლად გითხრას, რა უნდა გააკეთო შემდეგ. ეს არ არის აპი, რომელზეც აშენებ: შენი რეპოზიტორიის deploy მას ანაცვლებს.

One-click app მზა პროდუქტია, რომელიც შენთვის ინსტალირდება: WordPress web ხაზზე, Ghost და Strapi app ხაზზე. მათ აკონფიგურირებ, არ წერ. თუ ბლოგი გინდა, ესაა უფრო მოკლე გზა და შემდეგი საკითხავი Ghost-ის გიდი ან Strapi-ის გიდია.

starter template ამ ორს შორისაა: ნამდვილი კოდი, საკმარისად პატარა, რომ ხუთ წუთში წაიკითხო, და უკვე მორგებული სერვერზე, რომელზეც წავა.

ოთხი წესი, რომელსაც ყველა starter მისდევს#

ჰოსტინგის app სერვერი შენი ლეპტოპი არ არის. ის container-ში ერთ პროცესს უშვებს, ამ პროცესს ზუსტად ერთ საჯარო პორტს აძლევს და მას ყოველ ჯერზე ერთნაირად რთავს. პირველი deploy-ის თითქმის ყველა მარცხი ქვემოთ ჩამოთვლილი წესებიდან რომელიმეს არღვევს, ამიტომ ყველა starter სწორედ მათზეა აგებული.

პორტი. Pterodactyl-ზე აგებულ პანელში პორტი, რომელსაც შენი სერვერი ფლობს, პროცესს გადაეცემა გარემოს ცვლადით SERVER_PORT. ჩვენი Node.js და Python starter-ები სათადარიგოდ PORT-საც კითხულობენ, რომელსაც ბევრი პლატფორმა იყენებს, და შემდეგ ლოკალურ ნაგულისხმევ მნიშვნელობას, რომ იგივე ფაილი შენს მანქანაზეც გაეშვას. მისამართი პორტივით მნიშვნელოვანია: აპი, რომელიც localhost-ზე ან 127.0.0.1-ზე უსმენს, მხოლოდ საკუთარი container-ის შიგნით პასუხობს. კონსოლში ჯანმრთელი ჩანს, ინტერნეტიდან კი მიუწვდომელია. 0.0.0.0 ყველა ინტერფეისს ნიშნავს და ერთადერთი მისამართია, რომელიც მუშაობს.

Start. runtime-მა უნდა იცოდეს, რა გაუშვას. Node.js-ისთვის ეს package.json-ის start სკრიპტია. Python-ისთვის - Startup ჩანართზე მითითებული ფაილი, ნაგულისხმევად app.py, რომელიც requirements.txt-ის ინსტალაციის შემდეგ გაეშვება. web ჰოსტინგ სერვერს არც ერთი არ სჭირდება: მისი საკუთარი web სერვერი web root-იდან index.html-ს გასცემს.

ვერსია. .nvmrc და .python-version ამბობს, რომელი major ვერსიისთვის დაიწერა კოდი. სერვერი მაინც იმ ვერსიით მუშაობს, რომელიც GitHub ჩანართზე Runtime version-ში აირჩიე, ამიტომ ფაილი შეხსენება და შემოწმებაა და არა გადამრთველი. თუმცა pre-flight შემოწმება მას კითხულობს და გატყობინებს, როცა ორი ერთმანეთს არ ემთხვევა. ეს ძალიან გამოგადგება, როცა Next.js შენ მიერ შემთხვევით არჩეულ ვერსიას აღარ უჭერს მხარს.

საიდუმლოებები. ყველა starter-ს თან აქვს .env.example პარამეტრების სახელებით და ყალბი მნიშვნელობებით, და .gitignore, რომელიც ნამდვილ .env-ს გარეთ ტოვებს. ნამდვილ მნიშვნელობებს სერვერზე შეავსებ. რატომ და როგორ - წაიკითხე გარემოს ცვლადები და საიდუმლოებები.

ექვსი starter და რას უშვებენ ისინი#

ჩვენ ექვს starter რეპოზიტორიას ვინახავთ. თითოეული აგებული და გატესტილია პანელის საკუთარი pre-flight შემოწმებით, ამიტომ მისგან შექმნილ რეპოზიტორიაში გასასწორებელს არაფერს აჩვენებს. ისინი მხოლოდ იმ სერვერებზე გვთავაზება, რომელთა runtime ემთხვევა.

Bun-ის, Deno-ს, Go-ს, Java-ს, Rust-ის, .NET-ისა და Laravel-ისთვის starter ჯერ არ არსებობს. Node starter-ები .env-ს მხოლოდ Node-ის გამოძახებით კითხულობენ და Node-ის ვერსიას აფიქსირებენ, რასაც Bun-ისგან გარანტირებულად ვერ მივიღებთ, და ჩვენ უკეთესია არაფერი შემოგთავაზოთ, ვიდრე შეუმოწმებელი template. ბოლო განყოფილებაში ვწერთ, როგორ დაიწყო ეს runtime-ები ცარიელი რეპოზიტორიიდან.

ცარიელი სერვერიდან მუშა აპამდე, ნაბიჯ-ნაბიჯ#

ეს Express starter-ის სრული გზაა Node.js სერვერზე. დანარჩენი starter-ები მხოლოდ იმით განსხვავდებიან, რა სერვერს ყიდულობ და რა პარამეტრებს ავსებ.

1. შეუკვეთე სერვერი, რომელიც კოდს გაუშვებს - Express-ისთვის Node.js გეგმა app ჰოსტინგიდან. ის გადახდის დადასტურებისთანავე იქმნება, ჩვეულებრივ ერთ წუთში.
2. გახსენი სერვერის GitHub ჩანართი და დააჭირე Connect GitHub-ს. ეს შენს ანგარიშზე აყენებს RE:NODE GitHub App-ს და საშუალებას გაძლევს აირჩიო, რომელი რეპოზიტორიები დაინახოს. App მოკლევადიან ტოკენებს იყენებს, ამიტომ კერძო რეპოზიტორიებიც მუშაობს.
3. Start from a template-ის ქვეშ დააჭირე Use template-ს Express API-ზე. ეს გახსნის GitHub-ის საკუთარ გვერდს "create a repository from a template" შემოთავაზებული სახელით. აირჩიე მფლობელი, საჯარო ან კერძო და შექმენი. პანელი შენს ანგარიშში თავად არაფერს ქმნის - ამას GitHub აკეთებს, სადაც უკვე შესული ხარ.
4. დაბრუნდი პანელის ჩანართზე. რეპოზიტორიების სია ჩანართის ფოკუსის დაბრუნებისას განახლდება. თუ App-ს მხოლოდ არჩეული რეპოზიტორიები გაუზიარე, ჯერ ახალი Manage repository access-ში დაამატე.
5. აირჩიე რეპოზიტორია, production branch დატოვე main-ზე და აირჩიე Runtime version - Node 22 ყველა Node starter-ისთვის.
6. დააჭირე Deploy-ს. პანელი დადასტურებას გთხოვს, რადგან ეს სერვერს რეპოზიტორიიდან თავიდან აინსტალირებს. ახალ სერვერზე დასაკარგი არაფერია.
7. გაუშვი სერვერი. კონსოლში გამოჩნდება დამოკიდებულებების ინსტალაცია, შემდეგ კი Listening on 0.0.0.0: და შენი პორტი.
8. გახსენი სერვერის მისამართი და პორტი ბრაუზერში. მიიღებ პატარა JSON პასუხს შეტყობინებითა და აპის სახელით.

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

თუ მისამართისა და პორტის ნაცვლად დომენის გამოყენება გირჩევნია, ამას app გეგმებზე proxy slot აგვარებს: A ჩანაწერი მიუთითე ნაჩვენებ მისამართზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება. შენი აპი თავის პორტზე აგრძელებს მოსმენას; proxy მის წინ დგას, ხოლო კლიენტის რეალური IP X-Forwarded-For-ში მოდის.

რა დევს თითოეულ starter-ში#

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

Express API

server.js კითხულობს არასავალდებულო .env-ს, აყენებს სამ route-ს და იწყებს მოსმენას. მნიშვნელოვანი ბოლო რამდენიმე ხაზია:

const port = Number(process.env.SERVER_PORT || process.env.PORT || 3000);app.listen(port, '0.0.0.0', () => {    console.log(`Listening on 0.0.0.0:${port}`);});

.env იკითხება Node 22-ის ჩაშენებული process.loadEnvFile()-ით, ამიტომ dotenv დამოკიდებულება არ არის. npm run start უშვებს node server.js-ს; აწყობა საჭირო არ არის. starter-ის შემდეგ რა გელის - შეცდომების დამუშავება, ლოგირება, სწორი გაშვება - ნახე Express API-ის production-ზე deploy.

Next.js

Next.js starter App Router საიტია მთავარი გვერდითა და /api/health route-ით. მისი start სკრიპტი ჯერ აგებს და შემდეგ ემსახურება:

{  "scripts": {    "dev": "next dev",    "build": "next build",    "start": "next build && next start -H 0.0.0.0 -p $SERVER_PORT"  }}

გაშვებისას აწყობა ნიშნავს, რომ ყოველი რესტარტი საიტს თავიდან აგებს. ეს უფრო ნელია, ვიდრე commit-ში შენახული build-ის მიწოდება, მაგრამ სანაცვლოდ სერვერი ყოველთვის ზუსტად იმ commit-ს უშვებს, რომელიც აიღო, და Git-ში არ არის .next საქაღალდე, რომელიც მოძველდებოდა. ფასი მეხსიერებაა: next build პატარა Next.js საიტის ყველაზე ხარბი ოპერაციაა. თუ კონსოლში ყველაზე პატარა გეგმაზე build ჩამოვარდნას ხედავ, ეს მეხსიერების ლიმიტია და არა ბაგი - ლიმიტზე container swap-ის ნაცვლად ჩერდება და სუფთად გადაიტვირთება. build-ის დროს მეხსიერების გრაფიკს თვალი ადევნე და თუ ხაზს ეხება, გეგმა გაზარდე. Next.js-ის deploy Node სერვერზე უფრო დაწვრილებით განიხილავს standalone output-სა და build-ის ქეშირებას.

FastAPI

app.py ქმნის აპს და uvicorn-ს თავად უშვებს, ბრძანების ხაზზე დაყრდნობის გარეშე:

if __name__ == "__main__":    port = int(os.environ.get("SERVER_PORT", os.environ.get("PORT", "8000")))    uvicorn.run(app, host="0.0.0.0", port=port)

მისამართი და პორტი კოდშია, რადგან Python სერვერი ფაილს უშვებს, ხოლო ფაილს, რომელიც საკუთარ სერვერს თავად რთავს, დავიწყებული flag-ის გამო არასწორ მისამართზე ვერ გაუშვებ. requirements.txt fastapi-ს, uvicorn-სა და python-dotenv-ს ზუსტ ვერსიებზე აფიქსირებს და ყოველ გაშვებამდე ინსტალირდება. ინტერაქტიული დოკუმენტაცია პირველივე გაშვებიდან /docs-ზეა. FastAPI-ისა და Flask-ის deploy-ის გიდი worker-ებსა და production პარამეტრებს განიხილავს.

Discord bot

discord.js ბოტი ერთი გლობალური slash ბრძანებით, /ping. ის კითხულობს DISCORD_TOKEN-ს და თუ ის არ არის, ბიბლიოთეკის სიღრმეში ჩავარდნის ნაცვლად გასაგები შეტყობინებით ჩერდება. ბოტს შემომავალი პორტი არ სჭირდება, მაგრამ თუ სერვერს აქვს, starter მასზე პატარა JSON health check-ს პასუხობს, რომ uptime monitor-მა რაღაც იკითხოს. Discord-ისგან ის მხოლოდ Guilds intent-ს ითხოვს; შეტყობინებების შინაარსის წასაკითხად privileged intent გჭირდება, რომელიც Discord-ის developer portal-ში უნდა ჩართო და კოდშიც დაამატო. დანარჩენს ნახავ პოსტში Discord ბოტის ჰოსტინგი 24/7.

Telegram bot

python-telegram-bot-ის echo ბოტი, რომელიც /start-ს პასუხობს და ნებისმიერ ტექსტს უკან იმეორებს. ის long polling-ს იყენებს: ბოტი თავად ეკითხება Telegram-ს ახალ შეტყობინებებს, ამიტომ გარედან მასთან არაფერი უნდა მივიდეს და არც პორტი სჭირდება, არც დომენი. ეს ყველაზე მარტივი და სწორი ნაგულისხმევი ვარიანტია; webhook-ები მხოლოდ დიდ დატვირთვაზე ღირს და საკუთარ პრობლემებს მოაქვს, რომლებიც აღწერილია პოსტში Telegram webhook-ის პრობლემების მოგვარება.

Static site

index.html, 404.html და stylesheet root-ში, web ჰოსტინგ სერვერისთვის. start სკრიპტი არ არის და მისაბმელი პორტიც არა: სერვერის საკუთარი web სერვერი ფაილებს როგორც არის, ისე გასცემს. web root-ში ყველაფერი ვიზიტორს შეუძლია ჩამოტვირთოს, ამიტომ ამ starter-ში საიდუმლოებები საერთოდ არ არის. თუ მოგვიანებით bundler-ზე გადახვალ, ან აწყობილი შედეგი დააკომიტე, ან Where to put the code იმ საქაღალდეზე მიუთითე, სადაც ის დევს.

მორგება deploy-ის გაფუჭების გარეშე#

starter-ები შესაცვლელადაა. ზოგი ცვლილება ნებისმიერ დროს უსაფრთხოა, ზოგს სიფრთხილე სჭირდება.

თავისუფლად შეგიძლია შეცვალო: route-ები, გვერდები, handler-ები, აპის სახელი, სტილები, ფაილებისა და საქაღალდეების დამატება, დამოკიდებულებების დამატება. პაკეტს ამატებ npm install <name>-ით ან requirements.txt-ში ხაზის დამატებით, აკომიტებ განახლებულ lock ფაილს ან requirements-ს და აკეთებ push-ს. სერვერი შემდეგ გაშვებაზე ჩამოთვლილს დააინსტალირებს. package-lock.json აუცილებლად დააკომიტე; სწორედ ის ადგენს, რომ სერვერზე ინსტალაცია შენს მანქანაზე ჩატარებულს დაემთხვეს. ორ ინსტალაციის ბრძანებას შორის განსხვავება აღწერილია პოსტში npm ci vs npm install.

სიფრთხილით შეცვალე: listen გამოძახება, start სკრიპტი და entry ფაილის სახელი. ეს იგივე ოთხი წესია და სწორედ აქ აფუჭებს მუშა სერვერს უჩუმრად რეფაქტორინგი. სერვერის src/index.js-ში გადატანა ნორმალურია, თუ start მას გაჰყვება. app.py-ის main.py-ად გადარქმევა ნიშნავს, რომ Startup ჩანართზე მითითებული ფაილის სახელიც უნდა შეცვალო. თუ აპს ისეთ framework-ში ახვევ, რომელიც საკუთარ ნაგულისხმევ პორტზე უსმენს - ბევრი ასე იქცევა, ხშირად 3000, 5000 ან 8000 - სერვერის პორტი მას პირდაპირ უნდა გადასცე.

არასოდეს დააკომიტო: .env, ტოკენები, ბაზის პაროლები, კერძო გასაღებები. .env.example სერვერზე ფაილ მენეჯერით ან SFTP-ით დააკოპირე .env-ად და ნამდვილი მნიშვნელობები იქ შეავსე:

APP_NAME=my-apiDISCORD_TOKEN=paste-the-real-token-hereDATABASE_URL=postgres://user:password@host:port/dbname

რესტარტი ან push deploy ანულებს რეპოზიტორიიდან მოსულ ფაილებს და იგნორირებულ .env-ს ხელს არ ახლებს. თავიდან ინსტალაცია სხვაა: პირველი deploy ან runtime ვერსიის შეცვლა დირექტორიაში ყველაფერს ანაცვლებს. .env ატვირთე პირველი deploy-ის შემდეგ და ასლი უსაფრთხო ადგილას შეინახე - ეს ერთადერთი ფაილია, რომელსაც ახალი deploy ვერ აღადგენს.

ბაზის დამატება. app გეგმები მოიცავს ბაზის slot-ებს, რომლებიც პანელში იქმნება გენერირებული host-ით, მომხმარებლითა და პაროლით. connection string .env-ში ჩადე და არა კოდში. თუ აპი, ბაზა და cache ერთად გინდა, პანელის მაღაზიის Bundles ჩანართზე არსებული bundle ამას ერთ checkout-ში და ფასდაკლებით აკეთებს.

ყოველ push-მდე, რომელიც start-ს, პორტს ან runtime-ს ეხება, გადახედე GitHub ჩანართზე Pre-flight check ბარათს. ის რეპოზიტორიას GitHub-ზე კითხულობს - ხის ერთ სიას და რამდენიმე პატარა ფაილს, კლონირების გარეშე - და ჩამოთვლის, რა გაფუჭდება, ყველაზე სერიოზულიდან დაწყებული, ჩასასმელი გამოსწორებით: დაკარგული start სკრიპტი, localhost-ზე ან არასწორ პორტზე მიბმული აპი, დაკარგული build, runtime ვერსიის შეუსაბამობა, დაკომიტებული .env (დასახელებით აღინიშნება, არასოდეს იხსნება). starter ამ შემოწმებას პირველივე commit-ზე გადის; ბარათით კი იგებ, რომ შემდეგ ეს არ დაგიფუჭებია.

Deploy ყოველ push-ზე#

GitHub ჩანართს ორი გადამრთველი აქვს და მათ შორის წყდება, როდის გადადის ახალი კოდი ცოცხალზე.

• Pull the latest commit every time the server starts. რესტარტი branch-ს იღებს და ახალ კოდს უშვებს. push-ზე არაფერი ხდება; რესტარტს შენ ირჩევ.
• Restart the server when someone pushes to this branch. გაშვებული სერვერი push-იდან რამდენიმე წამში რესტარტდება და ახალ commit-ზე ბრუნდება. გაჩერებული სერვერი ირთვება, ამიტომ push ორივე შემთხვევაში ცოცხალზე გადადის.

ჰობი ბოტისთვის ან პირადი API-სთვის push-to-deploy სწორი ნაგულისხმევია: დააკომიტე, გააკეთე push და კონსოლს უყურე. იმისთვის, რაზეც ხალხი არის დამოკიდებული, deploy გააკეთე branch-იდან, რომელშიც ჩაფიქრებულად აკეთებ push-ს. main დატოვე იქ, სადაც სამუშაო ჩადის, ხოლო სერვერის production branch იყოს რაღაც production ან release და იქ მაშინ ჩაამატე, როცა ნამდვილად გინდა. ყოველი deploy იწერება, თითო deploy - თითო ჩანაწერი, ამიტომ კითხვას "რა მუშაობს ახლა" პასუხი აქვს.

ორი რამ უნდა იცოდე, სანამ ამას დაეყრდნობი. პირველი, Where to put the code-ში მითითებული საქაღალდე ყოველ გაშვებაზე რეპოზიტორიას უბრუნდება: ფაილ მენეჯერში პირდაპირ გასწორებული ფაილი, რომელიც Git-შია, შემდეგ deploy-ზე გაუქმდება, ხოლო თავიდან ინსტალაცია საქაღალდეს მთლიანად ასუფთავებს. გასწორება Git-ში გააკეთე, ატვირთვები და მონაცემები კი deploy საქაღალდეს გარეთ ამყოფე - ბაზაში ან object storage-ში. მეორე, რესტარტი რესტარტია. Next.js საიტი თავიდან აგებს, ბოტი თავიდან უკავშირდება და მიმდინარე მოთხოვნები იკარგება. Zero-downtime deploy პატარა სერვერზე და graceful shutdown შემდეგი ნაბიჯია, როცა ეს მნიშვნელოვანი გახდება.

deploy ტოკენი, რომლითაც პანელი შენს კოდს იღებს, სერვერის ყოველ გაშვებაზე ახლიდან იქმნება. სერვერზე გასაჟონი გრძელვადიანი GitHub გასაღები არ არსებობს.

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

starter პირველი deploy-ის მარცხების უმეტესობას აქრობს, მაგრამ არა ყველას. აი, რჩება ესენი.

• გვერდი არ იტვირთება, მაგრამ კონსოლი წესრიგშია. ალბათ არასწორ პორტზე შედიხარ ან შენ მიერ დამატებული რამ საკუთარ პორტზე უსმენს. კონსოლში მოძებნე პორტის ნომერი "listening" ხაზში და შეადარე სერვერის გვერდზე მითითებულ პორტს.
• `DISCORD_TOKEN is not set` ან `TELEGRAM_BOT_TOKEN is not set`. ბოტის starter-ები ტოკენის გარეშე განზრახ ჩერდებიან. ატვირთე .env ამ ცვლადით და გადატვირთე.
• ბოტი შედის, მაგრამ არავინ პასუხობს. Discord-ზე ბოტი სერვერზე უნდა მიიწვიო applications.commands scope-ით, სანამ slash ბრძანებები გამოჩნდება. Telegram-ზე შეამოწმე, რომ ბოტის სხვა ასლი - ვთქვათ, შენს ლეპტოპზე - იმავე ტოკენით polling-ს არ აკეთებს; ორი poller ერთსა და იმავე update-ებს ეჭიდება.
• ინსტალაცია ვერსიის შეცდომით ვარდება. ჩანართზე არჩეული Runtime version იმაზე ძველია, რაც კოდს სჭირდება. მისი შეცვლა სერვერს ახალ image-ზე ხელახლა აგებს, რაც მის დირექტორიაში ფაილებს რეპოზიტორიით ანაცვლებს; ბაზები და backup-ები ხელუხლებელი რჩება.
• Next.js build შუაში წყდება. მეხსიერების ლიმიტია. build-ის დროს შეამოწმე მეხსიერების გრაფიკი; გამოსავალი უფრო დიდი გეგმა ან უფრო მსუბუქი build-ია და არა განმეორება.
• სერვერი სულ ეცემა. crash loop შეიმჩნევა: დამკვირვებელი ითვლის ჩავარდნებს, რომელიც შენ არ მოგითხოვია, და საათში სამი ჩავარდნა სერვერის გვერდზე გაფრთხილებას აჩენს და ticket-ს ხსნის. წაიკითხე პირველი შეცდომა კონსოლში და არა ბოლო.
• რეპოზიტორია სიაში არ არის. GitHub App მხოლოდ იმ რეპოზიტორიებს ხედავს, რომლებიც მას გაუზიარე. ახალი რეპოზიტორია დაამატე Manage repository access-ში.

თუ შენი stack-ისთვის template არ არის#

Bun, Deno, Go, Java, Rust, .NET და Laravel სერვერებისთვის starter ჯერ არ არსებობს, მაგრამ ყველა მათგანი placeholder გვერდით იწყებს და იგივე ოთხი წესი ცარიელი რეპოზიტორიაც პირველივე ჯერზე გაეშვება.

Go-ზე სერვერი ყოველ გაშვებაზე go build-ით აგებს და ჩავარდნილი build გაშვებას აჩერებს, ძველ კოდს კი არ უშვებს. მინიმალური main.go:

package mainimport (    "fmt"    "net/http"    "os")func main() {    port := os.Getenv("SERVER_PORT")    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {        fmt.Fprintln(w, "hello")    })    http.ListenAndServe("0.0.0.0:"+port, nil)}

დააკომიტე ის go.mod-თან ერთად და pre-flight შემოწმება მის Go ვერსიას სერვერზე არსებულს შეადარებს. უფრო ვრცელი ვერსია იხილე Go web სერვისის deploy.

Bun-ზე package.json-ის start სკრიპტი bun install-ის შემდეგ გაეშვება. Deno-ზე deno.json-ის start ამოცანა გაეშვება deno task start-ით - და გაითვალისწინე, რომ Deno.serve ნაგულისხმევად 8000 პორტს იყენებს, ამიტომ სერვერის პორტი მას გადაეცი. Bun თუ Deno პატარა სერვერზე ორივეს ადარებს. Java-სთვის ნებისმიერი გასაშვები jar გამოდგება: Spring Boot, Quarkus, Micronaut ან Ktor Java 17, 21 ან 25-ზე, პორტით SERVER_PORT-იდან.

FAQ#

უნდა ვაწარმოო ჩემი რეპოზიტორიის სინქრონიზაცია template-თან?

არა. GitHub template-იდან შექმნილ რეპოზიტორიას მასთან კავშირი და საერთო ისტორია არ აქვს. template-ის განახლებები შენამდე არ აღწევს და შენი commit-ები არავისთან მიდის. თუ starter-ის მოგვიანებით ვერსიაში რაღაც გასწორდა, რაც შენთვის მნიშვნელოვანია, ცვლილება ხელით გადაიტანე, ისევე როგორც ნებისმიერი სხვა კოდი.

შეიძლება ჩემი რეპოზიტორია კერძო იყოს?

დიახ. GitHub-ის შექმნის გვერდზე აირჩიე private. პანელი GitHub App-ით დეპლოიებს მოკლევადიანი ტოკენებით, ამიტომ კერძო რეპოზიტორიები საჯაროების მსგავსად ითვლება. თუ მოგვიანებით AI context pull request-ს ჩართავ, საჯარო რეპოზიტორია მხოლოდ ზოგად წესებს მიიღებს და შენი სერვერის დეტალებს - არაფერს.

template-ის deploy წაშლის იმას, რაც უკვე ჩემს სერვერზეა?

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

რატომ არ აჩვენებს ჩემი Node.js სერვერი placeholder გვერდს?

placeholder გვერდი იწერება Node.js-ის გარდა ყველა runtime ხაზზე. ახალი Node.js სერვერი ცარიელი იწყებს, ამიტომ პირველ გაშვებამდე რეპოზიტორია დაადეპლოე - starter ან შენი საკუთარი.

შემიძლია starter სხვა ჰოსტზე გამოვიყენო?

დიახ. მათში არაფერია ერთ პანელზე მიბმული, გარდა იმისა, რომ ჯერ SERVER_PORT-ს კითხულობენ, შემდეგ PORT-ს და ბოლოს ლოკალურ ნაგულისხმევს. ეს ფარავს პლატფორმების უმეტესობას, რომლებიც პორტის ცვლადს აყენებენ, და შენს საკუთარ მანქანასაც.

რამდენი ხანი სჭირდება push-ს, რომ ცოცხალზე გადავიდეს?

ჩართული push deploy-ის დროს გაშვებული სერვერი push-იდან რამდენიმე წამში რესტარტდება. საერთო დრო აპზეა დამოკიდებული: Express API თითქმის მაშინვე ბრუნდება, Next.js საიტი კი გაშვებისას თავიდან აგებს და იმდენს ანდომებს, რამდენსაც next build ამ გეგმაზე.