አንድ ሰርቨር ላይ የብዙ ድር ጣቢያዎች ማስተናገድ በNginx ቪርቹዋል ሆስት (Server Blocks)

Nginx ሰርቨር ቦሎክዎች በአንድ Nginx አገልግሎት በተለያዩ የማዕከላዊ ስብስቦች ምርመራ በሚያደርጉበት በርካታ የድር አድራሻዎችን ወይም ድር ጣቢያዎችን በተለያዩ ውሂብ ማስተካከያዎች ለማቀርበት የሚያግዝ የvirtual host የስራ ሀሳብ ነው። ለምሳሌ በአንድ VPS ላይ example.com, blog.example.com እና ikinci-site.com ለተለያዩ የroot ድር ማስተካከያዎች, log ፋይሎች, SSL ማረጋገጫዎች እና PHP ማስተካከያዎችን ማቅረብ ይችላሉ። አጭር መፍትሄው፡ ለእያንዳንዱ ስፔስ የተለያዩ ድር ማስተካከያዎችን መፍጠር፣ የድር አድራሻዎች DNS መዝገቦችን ወደ ሰርቨር IP አድራሻ መመራመር፣ /etc/nginx/sites-available በበተለያዩ ሰርቨር ቦሎክ ማዘጋጀት፣ ወደ sites-enabled ድር መያያዝ፣ የconfiguration ማረጋገጥና Nginx አገልግሎትን እንደገና መጫን ነው።

በዚህ መምሪያ በNginx ሰርቨር ቦሎክዎች በተለያዩ ድር ጣቢያዎችን በማንኛውም production አካባቢ በተገቢው መልኩ እንዴት እንደሚያስቀመጡ እናሳያለን። ዓላማው እየሰራ ያለ ስርዓት ብቻ ሳይሆን፣ በቀላሉ የሚተዳደር፣ የሚያደነቅ፣ ፈጣን፣ የሚያዳን፣ እና በሚያስተካከል የሚሆን አደረጃዊ ስርዓት መፍጠር ነው። በተለይ ለኤጀንሲዎች፣ ለአንዳንድ ተግባራት ለሚሰሩ ልምድ ያላቸው ሰራተኞች፣ ለe-commerce ባለቤቶች፣ በተለያዩ ብራንድ ለሚተዳደሩ ድርጅቶች፣ እና በአንድ ሰርቨር ላይ በተለያዩ ፕሮጀክቶች ለሚሰሩ system administrators ለመሳሰሉ ሰዎች በተግባር የሚይዘውን እንዴት እንደሚያደርጋቸው እንካፈላለን። እስካሁን ሰርቨር የለዎትም ከሆነ ለምንጭ ምርጫ VPS ሰንበር እና ለየድር አድራሻ አስተዳደር ዶማይን ማስመዝገብ ገፆችን ማሳሰብ ይችላሉ።

Nginx ሰርቨር ብሎክስ ምንድነው?

Nginx ሰርቨር ብሎክስ በNginx አዋቂ ማዋቀር ውስጥ server ብሎክ ተብሎ የሚታወቀው እና የሚገባው HTTP ወይም HTTPS ጥያቄ ወደ የትኛው ድር ጣቢያ እንደሚያደርጉ የሚወስኑ የማዋቀር ክፍሎች ናቸው። Apache ላይ የሚገኘው VirtualHost አስተሳሰብ እንደዚህ ይመስላል። ጎተኞች በብሮውዘር የድር አድራሻ ሲጻፉ DNS ያህዌውን አድራሻ ወደ ሰርቨሩ የIP አድራሻ ያሳድዳል። ከዚያም Nginx በጥያቄ የተገኘው Host ራስጌ ይመልከታል እና server_name የሚዛመድ ሰርቨር ብሎክ ይሰራል።

በዚህ መንገድ በአንድ IP አድራሻ እና በአንድ ፍሪዚካል ወይም ቪርቹዋል ሰርቨር ላይ ከዚያ በላይ በርካታ የድር ጣቢያዎች ማስተላለፊያ ይችላሉ። ለእያንዳንዱ ጣቢያ የተለየ root ፎልደር, የግድያ log, የስህተት log, የመምሪያ ህግ, SSL ማህበረሰብ, cache ፖሊሲ እና የማህበረሰብ ህግ መወሰን የቻለው ነው። ለምሳሌ የኩባንያ ጣቢያዎን /var/www/kurumsal/public ውስጥ, ብሎጎን /var/www/blog/public ውስጥ, የሙከራ አካባቢዎን /var/www/staging/public ውስጥ ማከል ይችላሉ።

Nginx በዚህ አዋቂ ውስጥ በጣም ውጤታማ ነው ምክንያቱም በክስተት የተመሠረተው አስተሳሰቦቹ በጥቅም አውጪ የሚያስችሉ በጣም ብዙ አብራሪ ግንኙነት እንዲሰሩ ያደርጋል። ስለዚህ በማካያ hosting, VPS, ክላውድ ሰርቨር እና በከፍተኛ ትራፊክ ላይ የሚገኙ የመተግበሪያ መድረኮች በጣም ይመረጣል። በብዙ ጣቢያዎች በአንድ ሰርቨር ላይ በተደላይ እንዲሰሩ ከፍተኛ ውጤት ለማግኘት ከፋይል ፍቃድ እስከ DNS መምሪያዎች, SSL ማስገባት እስከ log ለያይ መለያየት ድረስ በሁሉም ዝርዝር ትክክለኛ የሆነ ዕቅድ ይወሰን አለበት።

Nginx የአገልጋይ ቦታዎች መተግበሪያ መቼ ነው?

Nginx የአገልጋይ ቦታዎች በአንድ አገልጋይ ላይ በርካታ የድር አቀማመጦችን ማስተዳደር ሲያስፈልግ ይጠቀሙበታል። ይህ አንዳንድ ጊዜ ሁለት ትንሽ የኩባንያ ሳይቶች ሊሆኑ ይችላሉ፣ ወይም የደንበኞች ፕሮጀክቶች፣ ንዑስ የድር አድራሻዎች ወይም micro service እንደ Hostragons የሚጠቀሙበት ሊሆን ይችላል። እዚህ በጣም አስፈላጊው ነገር እያንዳንዱ ፕሮጀክት ከሌላው በአእምሮ ይለየዋል።

• በአንድ VPS ላይ ከአንዱ በላይ የድር አድራሻዎችን ማስተናገድ ከፈለጉ።
• www ከሆነው እና ያልሆነው የድር አድራሻዎችን ወደ አንድ ካኖኒካል አድራሻ ማስተላለፍ ከፈለጉ።
• ንዑስ የድር አድራሻዎችን ወደ በተለያዩ ፋይሎች ወይም መተግበሪያዎች ማገናኘት ከፈለጉ።
• ለእያንዳንዱ ሳይት የተለየ SSL ማስረጃ እና የደህንነት ፖሊሲዎች መግለጽ ከፈለጉ።
• የደንበኞች ፕሮጀክቶችን በተለየ log ፋይሎች በመከታተል ከፈለጉ።
• Laravel, WordPress, static HTML, Node.js እና ሌሎች መተግበሪያዎችን በአንድ አገልጋይ ላይ በአንድነት ማስተናገድ ከፈለጉ።

ለምሳሌ፣ የዲጂታል ድርጅት በአንድ 4 GB RAM VPS ላይ 8 ትንሽ የኩባንያ ሳይቶችን መስመር ላይ ማውጣት ቴክኒካዊ ሊቻል ይችላል። ነገር ግን፣ ለእያንዳንዱ ሳይት የትራፊክ፣ የዲስክ መጠቀም፣ የPHP ፕሮሴሶች ቁጥር፣ የውስጥ መረጃ ታንኳኳት እና የቅድመ አድማ ደግሞ ይወሰናሉ። ፕሮጀክቶቹ ከፍተኛ ትራፊክ ከሚያገኙ ወይም የምንጭ አይዞለኝነት ከተወሰነ ከሆነ፣ የበለጠ ግልጽ VPS, cloud server ወይም የሚተዳደር hosting መፍትሄዎች ይመከራሉ። በዚህ አካል የድር ሆስቲንግ እና የድርጅት ሆስቲንግ አማራጮችን ማወዳደር ይቻላል።

መጀመሪያ ሳይጀምር የሚያስፈልጉ ነገሮች

በዚህ መምሪያ ላይ Ubuntu ወይም Debian የተመሰረተ Linux አስተናጋጅ እንደ መሰረት እንደምንም እንደምናውቅ ተይዞ ይታየዋል። ትንሽ የተለያዩ አይነት ትእዛዞች ከተለያዩ distribution አካባቢዎች ሊኖሩ ይችላሉ፤ ነገር ግን አጠቃላይ ሂደት አንድ ነው። በProduction አካባቢ ላይ ከተግባር በፊት ሁሉንም ያስቀምጡ። በትክክል ያልተሰራ የNginx ቅንብር ሁሉንም site ለቅጽበት አዳራሽ ሊያደርግ ይችላል።

የአስፈላጊ ቴክኒክ ዝግጅቶች

• Root ወይም sudo ስለሚችል የLinux መለያ ተጠቃሚ።
• ተገጥሞ የሚሰራ Nginx አገልግሎት።
• ወደ አስተናጋጅ የIP አድራሻ የተቀየረ ቢያንስ አንድ የDomain ስም።
• 80 እና 443 ፖርቶች በfirewall ክፍት ተደርጓል።
• የsite ፋይሎች ለማደራጀት ተደራሽ የድርሻ መዋቅር።
• SSL ለማጠቃለያ ትክክለኛ የcertificate ወይም ነፃ Let’s Encrypt አጠቃላይ።
• PHP የተመሰረቱ መተግበሪያዎች ሲኖሩ PHP-FPM ትክክል ማጠቃለያ።

በDNS አካባቢ ላይ A መዝገብ ዋናውን domain ስም ወደ IPv4 አድራሻ ይልካል። የAAAA መዝገብ ከሆነ ወደ IPv6 አድራሻ ይልካል። እንደ www ያሉ ንዑስ domain ስሞች ለማደራጀት CNAME ወይም A መዝገብ ይጠቀሙ። የDNS ስርጭት ብዙውን ጊዜ በጥቂት ደቂቃዎች እስከ 24 ሰዓት ይሆናል። አዲስ ቅንብር ሲሰሩ በመጀመሪያ DNS መዝገቦችን ማዘጋጀት ከዚያም Nginx server blocks ቅንብር ማስተካከል ሂደቱን የቀላል ያደርጋል።

የሚያሳምነው የፋይል አቀማመጥ

በብዙ ድር ጣቢያዎችን አከልከል ማድረግ ሲታይ በጣም የሚደገፉ ስህተቶች አንዱ ሁሉንም ፋይሎች በአንድ ቅርጸ ፋይል በተያያዙ ሁኔታ ማከል ነው። ይህ አፈጻጸም በአጭር ጊዜ ቀላል ይታያል ነገር ግን በመጠናቀቂያ፣ በመቆለለ፣ በስህተት ማስተካከል ሂደቶች ላይ ብዙ ጊዜ ያጠፋል። የተሻለ መንገድ፣ ለእያንዳንዱ የድር አድራሻ የተለየ ዋና ፋይል ማህደር እና በውስጥ public, logs, backups ያሉ አናት ፋይሎችን መጠቀም ነው።

ምሳሌ አቀማመጥ እንዲህ ሊያደርጉ ይችላሉ፡ /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public እና /var/www/site2.com/logs። የNginx root ዋጋ በቀጥታ public ፋይል ማህደር ያሳያል። እንዲሁ የመተግበሪያ ፋይሎች፣ .env ያሉ የሚገኙ የተለያዩ ፋይሎችና ቅድሚያዎች በድር ላይ በቀጥታ የሚደርሱ አይደሉም።

ለምሳሌ የstatik መለያ ገጽ ለእያንዳንዱ የማህደር ሳጥን ቀላል index.html ፋይል ማከል ይችላሉ። በውስጡ የድር ስም በመጻፍ የምንቀርበው አደራ የሚሰራውን በፍጥነት ማረጋገጥ ይችላሉ። በስራ አካባቢዎች እነዚህ ፋይል ማህደር ብዙውን ጊዜ የwww-data ተጠቃሚ ወይም በdeployment የሚሰራ ልዩ ተጠቃሚ ይይዛል። በፋይሎች ፍቃድ፣ ለማህደሮች 755 ፣ ለፋይሎች 644 በብዙ static ሁኔታዎች ይበቃል። WordPress ያሉ መተግበሪያዎች ለመጻፍ የሚያስፈልጉት uploads አካባቢ በተጨማሪ ሊታወቅ ይገባል።

Nginx ሰርቨር ብሎክ በአንድ አንድ እሴት ይፈጠራል

በታች ያሉ ደንቦች እንደ ምሳሌ site1.com የድር ስም በመጠቀም ተያይዞ ተዘረዘሩ። ይህንን ዘዴ ለሁለተኛ፣ ለሶስተኛ ወይም ለሌሎች ብዙ ስራ ማድረግ ይችላሉ። የጠቃሚው ነጥብ ለእያንዳንዱ ድር ብዙዕ server_name፣ root እና log ፋይል በተለያዩ መሆናቸው ነው።

1. የስ፣ይት ፋይል ቤት ያቁሙ

የመጀመሪያው እሴት የድር ፋይሎች የሚኖሩበት የማውጫ ፋይል መፍጠር ነው። ምሳሌ፡ sudo mkdir -p /var/www/site1.com/public። ከዚያ index.html የሚባል ፋይል በ /var/www/site1.com/public ውስጥ ያቁሙ እና "ይህ site1.com ለመሙከራ ገጽ ነው" የሚል መለያ ጽሑፍ ይጻፉበት።

የፋይል ባለቤትነትን ትክክለኛ ለማድረግ sudo chown -R www-data:www-data /var/www/site1.com የሚባል ትእዛዝ ይጠቀሙ። የdeployment ስራዎችን በሌላ የተቃጠለ ተጠቃሚ ከዚያው የመደበኛ ቡድን እውቅና ያድርጉ። በproduction አካባቢ ሁሉም ሰው የሚፃፉበት 777 ፈቃድ ከመስጠት ይርቁ። ይህ ፈቃድ የወንጀለኞችን የማስገባት ማውጫ በመጠቀም ሊጥፋ ይችላል።

2. የሰርቨር ብሎክ ፋይል ያቁሙ

በNginx ውስጥ የተሰረዘ የልምድ አስተዳደር፣ አንቀት ያልሆኑ አዋቂዎችን /etc/nginx/sites-available ውስጥ ማድረግ እና የሚያንቀትበትን፣ /etc/nginx/sites-enabled ውስጥ በsymbolic link መገናኘት ነው። ምሳሌ፣ /etc/nginx/sites-available/site1.com ፋይል።

ቀላል HTTP ሰርቨር ብሎክ የሚከተለውን ይደግፋል፡ server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

በዚህ ውቅር listen 80 HTTP ትራፊክን ይታደስ፣ server_name የዚያች ብሎክ የሚያዳምጡትን የድር ስም ያሳያል፣ root የድር ፋይሎች የሚኖሩበትን የፋይል ቤት ያሳያል፣ index የተወሰኑ የመጀመሪያ ፋይሎችን ይግለፃል። try_files የደርሰውን ፋይል ወይም አይታወቅስ ከሆነ 404 ይሰጣል። ለstatic ድር ይህ ውቅር የበቂ ነው።

3. ድሩን ያንቀትቡ

ውቅሩን በሚንቀትበት ሁኔታ ለማድረግ symbolic link ይፍጠሩ፡ sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com። ይህ ዘዴ ፋይሎችን መቅዳት ከመስራት ይሻላል፣ አንድ main ውቅር ፋይል ላይ ብቻ ትሰራለህ። ማሻሻያ ካደረጉ ተያያዥ ፋይልም በቅርብ ይቀየራል።

የNginx ዲፎልት ገጽ በድርዎ ላይ እንዳይታየው የዲፎልት ውቅርን ማግደል ይችላሉ። ለዚህ /etc/nginx/sites-enabled/default ሊንኩን ይወስዱ። ነገር ግን ይህን ሳይሰሩ የራሳችሁ የሰርቨር ብሎክ ትክክለኛ እንደሚሰራ ያረጋግጡ።

4. ውቅሩን ይመርምሩና Nginx ይቀይሩ

ከባለው ማሻሻያ በኋላ sudo nginx -t በማድረግ የsyntax መርማሪ ይሰሩ። ሙከራ ከተሳካ sudo systemctl reload nginx በማድረግ ሰርቨሩን አቋም በማቅረብ ይቀይሩ። reload ትእዛዝ restart ከሚባለው ይሻላል፣ ሰርቨሩ የአሁኑን ግንኙነቶች በዝግ አያቀርብም።

ሙከራው ካልተሳካ የስህተቱ መልእክት ብዙውን ጊዜ የፋይል ስምና የመስመር ቁጥር ይሳያል። የተጎዳው ነጥብ፣ የተቀረው ፖይንት፣ የተሳሳተ ከስተር፣ የተሳሳተ የፋይል መንገድ ወይም የተደጋጋሚ server_name እንደሚከሰት የተለመደ ችግር ነው። ስህተቱ ካልተስተካከለ Nginx አይቀየር።

ሁለተኛና ሶስተኛ ሳይቶችን መጨመር

በዝርዝር የሳይት ማስተናገድ ውበት ከመጀመሪያ ትክክለኛ ማቋቋሚያ በኋላ ሂደቱ እንደገና ለመድጋጋት የተዘጋጀ ይሆናል። ለsite2.com /var/www/site2.com/public የሚባል ዲረክቶሪ ይፈጥራሉ፣ /etc/nginx/sites-available/site2.com የሚለውን ፋይል ይጻፉ፣ root እና log ዋጋዎችን በsite2.com ይቀይራሉ፣ symbolic link ያቆሙ፣ እና Nginx ፈተናውን ያካሂዱ።

ለሁለተኛው ሳይት ቀላል መዋቅር በዚህ ግምገማ ይለያያል፡ server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

ለእያንዳንዱ ሳይት የተለየ log መጠቀም በተግባር አስተዋዋቂ ነው። ምሳሌ አንድ ሳይት ላይ 404 ስህተቶች በጣም ሲጨምሩ ሌላ ሳይት ጭንቀት አይኖረውም። በተለየ log መዋቅር የስህተቱን ምንጭ በሰከንዶች ውስጥ ማግኘት ይችላሉ። በዚሁ አይነት ሁኔታ የትራፊክ ትንበያ፣ bot ጥልቅ ፍጥረት፣ ቆሎ ማገናኘትና የperformance ችግሮች በሳይት ደረጃ ሊከታተሉ ይችላሉ።

SSL እና HTTPS ማዋቀር

በ2026 SEO መደበኛ ስርዓት፣ HTTPS ከተቀደሰ የደህንነት ባህሪ በስተቀር እንደ ተጠቃሚ ዘመናዊነት እና የቴክኒክ ጥራት ምልክት ይቆጠራል። ብዙ ባለመታመን አሳየ በሚባሉ HTTP ጣቢያዎች የአሳሳት ምልክት ይታያል፤ ክፍያ፣ አባልነት፣ ፎርም ወይም የዳሰሳ ፓነል የሚያካትቱ ፕሮጀክቶች ላይ SSL አስፈላጊ ነው። በብዙ ስፋት ሲተከል ለእያንዳንዱ የድር አድራሻ ትክክለኛ ማረጋጋጫ ማህበር ይገባዋል። በHostragons ላይ SSL ፍላጎትዎን ለመሟሟ የ SSL ሰርቲፊኬታት ገፅ ይመልከቱ።

Let’s Encrypt ቢጠቀሙ Certbot በእያንዳንዱ የድር አድራሻ ማረጋጋጫ ማህበር ሊያወጣ ይችላል። በምሳሌው ሂደት certbot --nginx -d site1.com -d www.site1.com ትእዛዝ Nginx ማዋቀርን ያውቃል እና HTTPS ብሎክን ራሱ ይጨምራል። ነገር ግን በራስ ማዋቀር ተጠናቋል በሚል ወቅት ፋይሉን ማረጋገጥ ጥሩ ባህሪ ነው። የተሳሳተ የመስተካከያ ወይም የሚያዳጉ የserver block ችግሮች ሊኖሩ ይችላሉ።

በHTTPS ማዋቀር ብዙውን ጊዜ የ80 ፖርት ትራፊክ ወደ 443 ፖርት በቋሚ ተላላኪ ይዘው ይገባሉ። 301 redirect SEO ላይ የቋሚ መምሪያ ምልክት ይሆናል። www ትጠቀሙ ወይም አትጠቀሙ እንደምትፈልጉ ውሳኔ ይውሰዱ እና ሁሉንም ቅድመ-አርከት ወደ አንድ ካኖኒካል አድራሻ ያበዙ። ለምሳሌ https://www.site1.com በማንሳት ይፈልጉ ከሆነ https://site1.com ትርጉም የሚሆነውን ሁሉንም HTTP እና HTTPS www ትራፊክ ወደ www የሌለው አድራሻ ያስተላልፉ። ይህ የተደጋጋሚ ይዘት አደጋን ያቅርበዋል።

PHP እና WordPress ድርጣቶች ለሚሆኑ Nginx አገልጋይ ቦታዎች

በስታቲክ HTML ድርጣቶች ማቅረብ ቀላል ነው፤ ግን WordPress፣ Laravel ወይም ልዩ PHP መተግበሪያዎች ሲሆኑ PHP-FPM ማያያዣ ያስፈልጋል። በዚህ አይነት ሁኔታ index.php ፋይል ይታወቃል እና PHP ጥያቄዎች ወደ የሚመለከተው ሶኬት ይቅረታሉ። ለምሳሌ በUbuntu ላይ PHP 8.3 ጥያቄዎች ሶኬቱ /run/php/php8.3-fpm.sock ሊሆን ይችላል። እትም በአገልጋይ ላይ ይለያያል።

PHP የተመሰረተ ምሳሌ ልዩ መንገድ፡ server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

በWordPress ውስጥ ቀጣይ አገናኞች ንባቡ ለማስረጃ try_files $uri $uri/ /index.php?$args ቅርንጫፍ በጣም አስፈላጊ ነው። ከዚህ በተጨማሪ xmlrpc.php መዳረሻ፣ wp-login.php የፍለጋ ጥያቄ ግዴታ አወጣጣ፣ uploads ዲረክተሪ ውስጥ PHP ማከል ማውጣት እና የደህንነት መንገዶች ማሰብ ያስፈልጋል። በአንድ VPS ላይ WordPress ድርጣቶች ብዙ ካስተናገዱ፣ ለእያንዳንዱ ስፍራ የተለየ database፣ የተለየ user እና የተዘጋጁ update መጠንቀቅ ይጠቀሙ። ለWordPress hosting መካከል ተሻለ አማራጭ ሚፈልጉ ለሚሆኑ ወርድፕሬስ ሆስቲንግ በቀላሉ ሊተገበር ይችላል።

Nginx ሰርቨር ብሎክ ከ Apache VirtualHost የተያያዙ ውስጥ ልክ

Nginx እና Apache ወደ አንድ ዓላማ በተለያዩ አይነት አማራጮች ይደርሳሉ። ሁለቱም በአንድ ሰርቨር ውስጥ በርካታ የድህረገፅ አካላትን ማስተናገድ ይችላሉ። መምረጥ በተግባር አስፈላጊነቶች፣ በአስተዳደር ልምዶች እና በአፈጻጸም ተያያዥ አስተሳሰብ የተወሰነ ነው።

አፕሊኬሽኑ በ .htaccess መሠረት የተጣለ ምስጢራዊ መመሪያ ከሆነ Apache ቀላል ሊሆን ይችላል። ነገር ግን ለከፍተኛ ትራፊክ፣ reverse proxy፣ cache እና ዘመናዊ ማስተናገድ አስፈላጊነቶች Nginx በብዙ ፕሮጀክቶች የሚታመን ምርጫ ነው። በተወሰኑ መዋቅሮች Nginx reverse proxy እና Apache የኋላ ገጽ አፕሊኬሽን ሰርቨር አንድነት ሊሰራ ይችላል።

የደህንነት ምርጥ ልምዶች

በአንድ ሰርቨር ላይ በርካታ ድር ጣቢያዎችን ማከል ወጪን ለመቀነስ ይረዳል፤ ነገር ግን የደህንነት አግዳጅነትን ይጨምራል። ከአንድ ስፍራ የሚታየ ድንጋጌ ሌሎችን እንዳይያዝ ለመከላከል መቀመጫ እና የአነስተኛ ቅንብር መስፈርት ማጠናከር አስፈላጊ ነው።

• ለእያንዳንዱ ድር ጣቢያ የተለየ የመዳበሪያ ቋትና የመዳበሪያ ተጠቃሚ ያቁሙ።
• የድር የመሰረተ ዳር ፋይል ለ public ፎልደር ብቻ ያድርጉ።
• Backup, .env, .git, config እና SQL ፋይሎችን ከድር አገልግሎት ውጪ ያስቀምጡ።
• SSL ሰርተፍኬቶችን በየጊዜው ያደስሱና የHTTPS መሳሪያን ያስገድዱ።
• በሰርቨር ላይ UFW ወይም ተመሳሳይ የደህንነት ግንዛቤ ይጠቀሙ፤ የሚያስፈልጉትን ፖርቶች ብቻ ያክሉ።
• Nginx እና የኦፕሬቲንግ ሲስተም ዝማኔዎችን በየጊዜው ያተግቡ።
• ለእያንዳንዱ ድር ጣቢያ የተለየ access_log እና error_log ይዞ ያድርጉ።
• የአስተዳደር ፓነል ላይ IP ገደብ ወይም ተጨማሪ የመለያ ማረጋገጫ ያክሉ።
• ፋይል ፍቃድ ውስጥ ከ777 ያለውን አሰፋላሊ ፍቃድ ይቆጥቡ።

በተጨማሪም የመሰረታዊ ደህንነት ርዕሶችን ማከል ይረዳል። X-Frame-Options, X-Content-Type-Options, Referrer-Policy እና Content-Security-Policy ያሉ ርዕሶች ለተስተናጋጅ ፕሮጀክቶች ሊቀርበው ይችላል። ነገር ግን Content-Security-Policy በትክክል አይተደርግም ብለው ከተደረገ ፣ የ script እና የstyle ፋይሎችን ሊያዘው ይችላል፤ ስለዚህ መጀመሪያ በሙከራ አካባቢ ማሞከር ያስፈልጋል። ለአሰፋላሊ የደህንነት ዝርዝሮች የድር ገፅ ደህንነት ጽሑፎችን ማገናኘት ይችላል።

የፍጥነትና SEO ለሚያስፈልጉ ጉዳዮች

Nginx የሰርቨር ብሎክ ማድረግ ብቻ ሳይሆን፣ የድር ጣቢያውን ፍጥነትና SEO ጥራት እንዲረጋገጥ ይጠቅማል። የትስስር ተላላፊ የማይሆኑ ማዕከል ዝንባሌዎች፣ የትክክለኛው canonical ውጤት ማጣት፣ የgzip ወይም brotli ግፊት አለመኖር፣ ታላቅ log ፋይሎች እና የcache ቅንብሮች አባባል የስርዓቱን ፍጥነት ሊያንስ ይችላሉ። Google የገፅ ልምድ ምልክቶች ተጠቃሚ ትኩረት ይሰጣሉ፤ በፍጥነት የሚመልስ፣ የታመነ እና የተስተናጋገዘ ጣቢያዎች የበለጠ ውጤት ይሰጣሉ።

በመጀመሪያ ለእያንዳንዱ የድር ስም አንድ ብቻ canonical እትም ያዘጋጁ። ከHTTP ወደ HTTPS፣ ከwww ወደ www ያልሆነ ወይም በተቃራኒው አንድ ደረጃ የሚሆን ዝንባሌ ያድርጉ። ዝንባሌ የሚሆን አይደለም፡ http://site.com አንዳች http://www.site.com ወደ እንደ https://www.site.com ከዚያም https://site.com ወደሚሆን። ይህ ይህን በአንድ 301 ማዕከል በቀጥታ ወደ መግቢያ ይሄዱ።

ለስታቲክ ፋይሎች cache-control ራስጌዎች ሊጠቀሙ ይችላሉ። ምስሎች፣ CSS እና JS ፋይሎች በአንድ ጊዜ በbrowser ውስጥ ሊቆይ ይችላሉ። ነገር ግን በተደጋጋሚ የሚቀየሩ ፋይሎች ውስጥ የፋይል ስም ቅድመ ቅጥያ ወይም query string ስትራቴጅ ይጠቀሙ። gzip ግፊት HTML, CSS, JS እና JSON ያሉ አንቀሳቃሽ ውስጥ የባንድ አፍል ይቀንሳል። ትልቅ ትራፊክ የሚያገኙ ጣቢያዎች ላይ Nginx microcache፣ FastCGI cache ወይም CDN አጠቃቀም ይመረምሩ። CDN እና የዓለም አቀፍ ግብዓት ሲያስፈልጉ CDN ምንድነው ያሉ የውስጥ አገናኝ ማድረግ ይቻላል።

የሎግ አስተዳደርና እንቅስቃሴ

በርካታ site ማስተናገድ ውስጥ የሎግ አስተዳደር የችግር መፍትሄ ቁልፍ ነው። የተለያዩ log ፋይሎች የትኛው site ላይ የተፈጠረው ስህተት ግልጽ በሚያሳይ መልኩ ይያዙታል። access_log የጎብኚ ጥያቄዎችን ይመዝግባል፣ error_log ደግሞ የመዋቅር፣ ፈቃድ፣ ፋይል አልተገኘምና የupstream ስህተቶችን ይመዝግባል። 502 Bad Gateway ስህተት ብዙ ጊዜ PHP-FPM ወይም የback-end አገልግሎት ግንኙነት ጋር ይተያያዛል። 403 Forbidden የፈቃድ ወይም የindex ፋይል ችግር ሊሆን ይችላል። 404 Not Found ደግሞ የፋይል መንገድ፣ rewrite ወይም DNS በኋላ የተሳሳተ root ችግርን ሊያሳይ ይችላል።

የlog ፋይሎች ያልተገደበ እድገትን ለመከላከል logrotate ውቅር መቆጣጠር ያስፈልጋል። በትንሽ ፕሮጀክቶች ዕለታዊ ወይም ሳምንታዊ መዞር በቂ ሊሆን ይችላል። በከፍተኛ ትራፊክ ያላቸው site ላይ የማዕከላዊ log ማከማቻ፣ ሜትሪክ እንቅስቃሴና የማሳሰቢያ ስርዓቶች ሊያገለግሉ ይገባል። የdisk ሞልታ ስህተት Hostragons ወይም Nginx እንዳይመዝገብ log፣ የdatabase እንዳይሰራ እና site የተገናኙት እንዳይደርሱ ሊያደርግ ይችላል። ስለዚህ ለየያዩ disk አጠቃቀም threshold የማዘጋጀት በግልጽ የአዋጅ እርምጃ ነው።

የተወሰኑ ስህተቶች እና ፈጣን መፍትሄዎች

በNginx ሰርቨር ብሎክዎች ሲሰሩ ስህተቶች በአብዛኛው ፕሮጀክቶች ላይ ሊገኙ ይችላሉ። እነዚህን መረዳት የማቅረብ ጊዜዎን በግልጽ ሁኔታ ይቀንሳል።

• የድር ስም ትክክለኛ ሳይሆን ሌላ አድራሻ እንደገና ከፍተኛ ነው፡ server_name ግጭቶችን እና default server blockን ይመርምሩ።
• 403 Forbidden ስህተት፡ root ዲረክቶሪውን፣ ፋይል ፍቃድን እና index ፋይል አለዎትን ይቆጥሩ።
• 404 Not Found ስህተት፡ root መንገድን እና try_files ህግን ይመርምሩ።
• 502 Bad Gateway ስህተት፡ PHP-FPM አገልግሎቱ ተነስቷልን እና socket መንገዱ ትክክለኛ ነውን ያረጋግጡ።
• SSL ሰርቲፊኬት ትክክለኛ ሳይሆን ሌላ ስርዓት ላይ ይታያል፡ 443 port server_nameን እና ሰርቲፊኬት ፋይሉን ይቆጥሩ።
• የቀስታ የሚያደርጉ የሪያዲሬክት ዙር፡ HTTP-HTTPS እና www የሪያዲሬክት ህጎችን ያጠናክሩ።
• Nginx አዲስ አስተካክል አይደረግም፡ sudo nginx -t ውጤት ላይ ያለውን የsyntax ስህተት በትክክል ያስተካክሉ።

የተሞክሮ አስተዳደሮች የሚተግበሩ ቀላል የመከታተያ ዝርዝር አለ፡ DNS ትክክለኛ ነውን፣ Nginx ቅንብር አንቀሳቃሽ ነውን፣ root ፋይል አለውን፣ ፍቃድ ትክክለኛ ነውን፣ አገልግሎት ተፈተና አለበትን፣ log ምን ይናገራል? ይህንን ቅደም ተከተል ሲከተሉ በአንደኛ አይነት ቁልፍ ፈጣን መፍትሄ ማግኘት ይችላሉ።

ለልማት አካባቢ የተሟሟ የመቆጣጠሪያ ዝርዝር

ከስፋት ላይ ከማውጣት በፊት ከታች ያለውን ዝርዝር ተጠቃሚ በሆነ ንድፍ ሁሉንም ይፈትሹ። በተለይም የደንበኛ ፕሮጀክቶች ላይ ከማስረከብ በፊት እነዚህን የሚያሳይ ማስታወሻ የፕሮፌሽናል ስራ መስፈርት ያበረታታል።

• የDomain ስም A ወይም AAAA መዝገብ ትክክለኛ ወደ IP አድራሻ ይጠብቃል።
• www ያለውና የሌለው ስም ከነዚህ አንዱ በትክክል እንደ ካኖኒክ ተመረጠ።
• HTTP ትራፊክ በ 301 ወደ HTTPS ይልከዋል።
• SSL ሰርቲፍኬት ትክክል ነው እና አውቶማቲክ የዘመና ማድረግ አንቀሳቅሷል።
• ለእያንዳንዱ site በተለይ root እና log ፋይል ተወሰነ።
• Nginx ኮንፊግሬሽን sudo nginx -t አሟሟ።
• የቅድመ ቅጂ እቅድ ተዘጋጅቷል እና የመልስ ሙከራ ተደርጓል።
• የፋይል ፍቃድ በሚነቃቃ ፍቃድ መስፈርት ይራራል።
• በሴፍቲ ግድብ የሚያስፈልጉ ፓርቶች ብቻ ተከፍተዋል።
• የስህተት log ፋይሎች ከስፋት ላይ ከማውጣት በኋላ ቢያንስ 15 ደቂቃ ተቆጣጠሩ።

ይህ ዝርዝር ትንሽ የመጣው ቢመስልም በእውነተኛ ፕሮጀክቶች ውስጥ የአገልግሎት እናት አደጋን በግምት ያሳነሳል። በተለይም SSL ዘመና, DNS መቆጣጠር እና log እይታ እነዚህ አካላት ብዙ የማይታየውን እና የተደበቀውን ስህተት ቀድሞ ይያዛሉ።

መደምደሚያ

Nginx ሰርቨር ብሎክዎች በአንድ ሰርቨር ላይ ብዙ ድርጅቶችን በተስተናት ፣ ደህንነት እና ከፍተኛ አፈጻጸም የሚያሳዩ የመስተናት መንገዶች መካከል አንዱ ነው። ትክክለኛ የድርጅት መዋቅር፣ የተለያዩ የውቅር ፋይሎች፣ ግልጽ የመምሪያ መስፈርቶች፣ HTTPS አጠቃቀም፣ የሎግ ልዩነት እና በየጊዜው የሚደርስ ሙከራ በብዙ ሰብስክቶች ማስተናገድን በጣም የሚያሳልፉ ያደርጋሉ። ከትንሽ የፖርትፎሊዎ ድርጅት እስከ ብዙ የደንበኞች ፕሮጀክቶች ድረስ አንደኛው መሠረት ለሁሉም ይሰራል።

አዲስ ፕሮጀክት በመጀመር ላይ ከሆኑ አንዳንድ ነጥቦችን በመመርመር የድር ስም፣ የሰርቨር ምንጭ እና SSL ፍላጎቶችዎን ግልጽ ያድርጉ፤ ከዚያም በላይ ያለውን የቁጥጥር ዝርዝር በመከተል የNginx ውቅርዎን በእርስዎ ቅድመ እርምጃ ያዘጋጁ። በቀላሉ የሚተዳደር መስመር ከፈለጉ ከHostragons የ[inç-link: Hosting Paketleri]፣ [inç-link: VPS አገልጋይ] እና [inç-link: SSL Sertifikaları] መፍትሄዎችን በመተንተን ለፕሮጀክትዎ ተገቢ የመጀመሪያ ነጥብ ማምረጥ ይችላሉ።

በተደጋጋሚ የሚጠየቁ ጥያቄዎች

በNginx ሰርቨር ብሎክ ምን ያህል ድር ጣቢያ ማስተናገድ ይቻላል?

በቴክኒክ ሁኔታ Nginx ላይ በአንድ ሰርቨር ብዙ ድር ጣቢያዎች ማስተናገድ ይቻላል፤ ውስጥ አቅም ብዛት የሚወሰንው በCPU፣ RAM፣ ዲስክ፣ ትራፊክ፣ የውስጥ መረጃ ማከማቻ እና PHP-FPM አቅም ነው። በቅርብ ትራፊክ ያላቸው ስታቲክ ስርዓቶች ውስጥ የተወሰኑ ትርፍ ያላቸው ድር ጣቢያዎች ማስተናገድ ይቻላል፤ ነገር ግን በርካታ WordPress ወይም ኢ-ንግድ ፕሮጀክቶች ውስጥ በትንሹ መስተናገድ ይሻላል።

ለእያንዳንዱ ድር ጣቢያ የተለየ SSL ሰርቲፍኬት ያስፈልጋል?

አዎ፣ የእያንዳንዱ የድር ጣቢያ ስም ወይም ሳብዶሚን በHTTPS ሊታይ ከሚፈልጉ መሆኑ የሚሆነው በሰርቲፍኬት ውስጥ ይጨመር። አንድ በአንድ ሰርቲፍኬት የሚያገለግሉ ይችላሉ፣ ወይም SAN ወይም wildcard ሰርቲፍኬቶችን ለውጥ ማድረግ ይችላሉ። አስፈላጊው ሰርቲፍኬት ፋይሎች በNginx 443 ሰርቨር ብሎክ ላይ በትክክል ከየድር ጣቢያ ስም ጋር የተያዙ መሆናቸው ነው።

በNginx ሰርቨር ብሎክ ሳብዶሚን ማስተናገድ ይቻላል?

አዎ። blog.site.com ወይም panel.site.com እንደሚሆኑ ሳብዶሚን ለእያንዳንዱ server_name በትክክል ማስረጃ ይችላሉ፣ በሚፈልጉት ሩት ዲሬክቶሪ ወይም በተለያዩ መተግበሪያዎች ማድረግ ይችላሉ። ከDNS ወገን ለተወሰኑ ሳብዶሚን በA ወይም CNAME መዝገብ ማቅረብ ይኖርበታል።

sites-available እና sites-enabled ልዩነት ምንድነው?

sites-available በሚፈገጉ ኮንፊግሬሽን ፋይሎችን የሚያከማቸው ቦታ ነው፤ sites-enabled ደግሞ በአሁኑ ጊዜ የሚሰሩ ኮንፊግሬሽኖችን ይይዛል። በተለምዶ sites-enabled ውስጥ በsites-available ተገናኝ symbolic link ይቀርባል። ይህ ዘዴ ስፋት ማስነሳት እና ማወጣት ቀላል ያደርገዋል።

የትኛውም ድር ጣቢያ በትክክል አይከፈትም ከሆነ ችግሩ ከየት ይመጣል?

በአብዛኛው DNS የትክክል የIP አይነት ስር አይደለም፣ server_name ዋጋ ተሳሳተ፣ default Nginx ብሎክ ጥያቄውን ይይዛል፣ ወይም በ443 የተሳሳተ SSL ብሎክ ይሰራል። በመጀመሪያ DNS መዝገቦችን፣ nginx -t ውጤት፣ አንድ sites-enabled ሊንኮችን እና access_log ፋይሎችን ሙሉ ያረጋግጡ።