Վեբ սերվեր CentOS 8-ում php7-ով, node.js-ով և redis-ով

Նախաբան

Արդեն 2 օր է, ինչ թողարկվել է CentOS օպերացիոն համակարգի նոր տարբերակը, այն է՝ CentOS 8: Եվ մինչ այժմ համացանցում բավականին շատ հոդվածներ կան այն մասին, թե ինչպես են գործերը կատարվում դրանում, ուստի ես որոշեցի լրացնել այս բացը: Ավելին, ես ձեզ կպատմեմ ոչ միայն այն մասին, թե ինչպես տեղադրել այս զույգ ծրագրերը, այլ նաև այն մասին, թե ինչպես եմ ընդհանուր առմամբ տեսնում Linux-ի տեղադրումը վիրտուալ միջավայրում ժամանակակից աշխարհում բնորոշ առաջադրանքների համար, ներառյալ սկավառակների բաժանումը և այլն:

Բայց սկզբում ես ուզում եմ հակիրճ խոսել այն մասին, թե ինչու է արժե անցնել այս տարբերակին բոլոր նախորդներից, և դրա համար երկու պատճառ կա.

  1. php7! CentOS-ի նախորդ տարբերակում տեղադրվել էր «Ուղղափառ» php5.4...

    Լավ, մի քիչ ավելի լուրջ լինելու համար, շատ փաթեթներ զանգվածաբար ցատկեցին մի քանի տարբերակների միջով: Մենք (redhat-ի նման ՕՀ-ների երկրպագուները) վերջապես մտանք, եթե ոչ ապագա, ապա գոնե ներկա։ Իսկ Ubuntu-ի աջակիցներն այլևս չեն ծիծաղի մեզ վրա ու մատով ցույց կտան մեզ, լավ... գոնե մի որոշ ժամանակ ;):

  2. Անցում yum-ից dnf-ի: Հիմնական տարբերությունն այն է, որ այժմ պաշտոնապես աջակցվում է փաթեթների մի քանի տարբերակների հետ աշխատելը։ Հենց ութում ես երբեք չեմ գտել սա օգտակար, բայց դա խոստումնալից է թվում:

Ստեղծեք վիրտուալ մեքենա

Կան տարբեր հիպերվիզորներ, և ես նպատակ չունեմ ընթերցողին հարմարեցնել կոնկրետ մեկին, ես ձեզ կասեմ ընդհանուր սկզբունքների մասին:

հիշողություն

Նախ... 7-ից սկսած CentOS համակարգը հաստատ տեղադրելու համար, և իմ կարծիքով 6-ի դեպքում նույնպես այդպես էր («բայց սա հաստատ չէ»), պետք է. նվազագույն 2 ԳԲ RAM: Ուստի խորհուրդ եմ տալիս նախ այդքանը տալ։

Բայց եթե որևէ բան կա, տեղադրումից հետո հիշողության չափը կարող է կրճատվել: 1 ԳԲ-ում մերկ համակարգը բավականին լավ է աշխատում, ստուգեցի։

սկավառակ

Նորմալ տեղադրման համար պետք է ստեղծել 20-30 ԳԲ տարողությամբ վիրտուալ սկավառակ։ Սա բավական է համակարգի համար։ Եվ երկրորդ սկավառակ տվյալների համար: Այն կարող է ավելացվել ինչպես վիրտուալ մեքենայի ստեղծման փուլում, այնպես էլ դրանից հետո։ Ես սովորաբար այն ավելացնում եմ ավելի ուշ:

Պրոցեսոր

Մեկ միջուկի վրա մերկ համակարգը չի դանդաղում: Եվ քանի որ ռեսուրսներն ազատորեն մասշտաբավոր են, ես տեղադրման փուլում ավելին տալու իմաստ չեմ տեսնում (եթե դուք լավ չգիտեք պահանջները և չափազանց ծույլ եք նորից մտնել կոնֆիգուրատոր)

Մնացածը սովորաբար կարելի է թողնել որպես լռելյայն:

Փաստացի տեղադրում

Այսպիսով... Եկեք գործարկենք տեղադրիչը... Անձամբ ես նման ծառայությունները տեղադրում եմ միայն վիրտուալ մեքենաների տեսքով վաղուց, այնպես որ ես չեմ նկարագրի բաշխման բոլոր տեսակի գրառումները ֆլեշ կրիչի վրա. ես պարզապես տեղադրում եմ: ISO-ն որպես CD իմ սիրելի հիպերվիզորում, ներբեռնեք և գնացեք:

Հիմնական տեղադրումը բավականին բնորոշ է, ես կանդրադառնամ միայն մի քանի կետերի վրա:

Աղբյուրի ընտրություն

Ութերորդ տարբերակի թողարկումից ի վեր Yandex-ի հայելին օրեր շարունակ պառկած է: Դե, այսինքն, այն պարբերաբար բարձրանում է, իսկ հետո նորից սկսում է սխալ ցույց տալ: Համոզված եմ, որ դա ծառայության վրա ավելորդ ծանրաբեռնվածության պատճառով է: Ուստի, աղբյուրը նշելու համար, անձամբ ես ստիպված էի, սովորական հասցեն մտնելու փոխարեն, գնայի այստեղ, ընտրեք այնտեղ ինձ դուր եկած հայելին և տեղադրողի պատուհանում ձեռքով մուտքագրեք հասցեն: Այստեղ կարևոր է հիշել, որ դուք պետք է նշեք այն թղթապանակի ուղին, որտեղ գտնվում է գրացուցակը repodata. Օրինակ, mirror.corbina.net/pub/Linux/centos/8/BaseOS/x86_64/os.

Սկավառակի բաժանում

Այս հարցը, իմ կարծիքով, բավականին կրոնական է։ Յուրաքանչյուր ադմին ունի իր դիրքորոշումն այս հարցում։ Բայց ես դեռ կկիսեմ իմ տեսակետը հարցի վերաբերյալ։

Այո, սկզբունքորեն, դուք կարող եք ամբողջ տարածքը հատկացնել արմատին, և այն կաշխատի, ամենից հաճախ նույնիսկ բավականին լավ: Այդ դեպքում ինչո՞ւ ցանկապատել այգին տարբեր հատվածներով: — Իմ կարծիքով, դրա համար երկու հիմնական պատճառ կա՝ քվոտաները և տեղափոխելիությունը։

Օրինակ, եթե ինչ-որ բան սխալ է, և սխալներ են տեղի ունենում տվյալների հիմնական բաժանման վրա, դուք ցանկանում եք, որ դեռ կարողանաք բեռնել համակարգը և իրականացնել վերակենդանացման միջոցառումներ: Հետեւաբար, ես անձամբ հատկացնում եմ առանձին բաժին /boot-ի համար: Կա միջուկ և բեռնիչ: Սովորաբար 500 մեգաբայթը բավական է, բայց հազվադեպ դեպքերում կարող է ավելին անհրաժեշտ լինել, և հաշվի առնելով, որ մենք արդեն սովոր ենք տարածքը տերաբայթով չափել, այս բաժնի համար հատկացնում եմ 2 ԳԲ։ Եվ այստեղ կարևորն այն է, որ դա հնարավոր չէ անել lvm:

Հաջորդը գալիս է համակարգի արմատը: Սովորական տեղադրման համար ես երբեք մեկ համակարգի համար 4 ԳԲ-ից ավելի կարիք չեմ ունեցել, բայց պլանավորված իրադարձությունների ժամանակ ես հաճախ օգտագործում եմ /tmp գրացուցակը բաշխումները բացելու համար, և ես իմաստ չեմ տեսնում այն ​​նվիրել առանձին բաժանման՝ ժամանակակից համակարգերում: այն ինքնաբերաբար մաքրվում է, ուստի այն չի լցվում: Այսպիսով, ես 8 ԳԲ եմ հատկացնում արմատի համար:

Փոխանակում... Մեծ հաշվով դրա գործնական օգուտը քիչ է: Եթե ​​դուք սկսեք օգտագործել swap ձեր սերվերի վրա, այսօր իրական աշխարհում դա միայն նշանակում է, որ սերվերը պետք է ավելացնի RAM: Հակառակ դեպքում, աշխատանքի հետ կապված խնդիրները երաշխավորված են (կամ որոշ ծրագրերի հիշողությունը «արտահոսում» է): Հետևաբար, այս բաժինը անհրաժեշտ է միայն ախտորոշիչ նպատակներով: Հետեւաբար, 2 ԳԲ-ը գերազանց թիվ է: Այո, անկախ նրանից, թե որքան հիշողություն կա սերվերի վրա: Այո, ես կարդացել եմ բոլոր այն հոդվածները, որտեղ գրված է հիշողության ծավալի և փոխանակման ծավալի հարաբերակցության մասին... IMHO, դրանք հնացած են։ 10 տարվա պրակտիկայի ընթացքում ես երբեք դրա կարիքը չեմ ունեցել: 15 տարի առաջ ես դրանք օգտագործել եմ, այո։

IMHO, յուրաքանչյուրը կարող է ինքնուրույն որոշել, թե արդյոք /home-ը հատկացնել առանձին բաժանման: Եթե ​​սերվերում ինչ-որ մեկը ակտիվորեն կօգտագործի այս գրացուցակը, ավելի լավ է այն հատկացնել: Եթե ​​ոչ ոք, ապա կարիք չկա։

Հաջորդը, / var. Իմ կարծիքով, դա միանշանակ պետք է կարեւորել։ Սկզբից կարող եք սահմանափակել ձեզ 4 ԳԲ-ով և տեսնել, թե ինչպես է դա ընթանում: Եվ այո, «ինչպես է գնում» ասելով ես դա նկատի ունեմ

  1. Նախ, դուք միշտ կարող եք մեկ այլ սկավառակ տեղադրել /var ենթագրքում (որը ես ավելի ուշ ցույց կտամ օրինակով)
  2. Երկրորդ, մենք ունենք lvm - դուք միշտ կարող եք ավելացնել այն: Եվ դուք սովորաբար պետք է ավելացնեք այն, երբ չափազանց շատ տեղեկամատյաններ սկսում են լցվել այնտեղ: Բայց ես երբեք չեմ կարողացել կանխատեսել այս ցուցանիշը նախապես, այնպես որ ես սկսում եմ 2 ԳԲ-ից և հետո դիտում:

Չբաշխված տարածքը կմնա ազատ ծավալի խմբում և միշտ կարող է օգտագործվել ավելի ուշ:

LVM

Բոլորը Իմաստ ունի LVM-ում /boot-ից այլ բաժանումներ անելը: Այո, ներառյալ փոխանակումը: Այո, ըստ բոլոր խորհուրդների, swap-ը պետք է լինի սկավառակի սկզբում, բայց LVM-ի դեպքում դրա գտնվելու վայրը սկզբունքորեն չի կարող որոշվել։ Բայց ինչպես վերևում գրեցի, ձեր համակարգը չպետք է լինի ընդհանրապես օգտագործել swap-ը: Հետևաբար, կարևոր չէ, թե որտեղ է նա: Դե, մենք 95-ին չենք ապրում, անկեղծ ասած:

Ավելին, LVM-ում կան մի քանի հիմնական սուբյեկտներ, որոնց հետ դուք պետք է կարողանաք ապրել.

  • ֆիզիկական ծավալը
  • ծավալային խումբ
  • տրամաբանական ծավալը

Ֆիզիկական ծավալները միավորվում են խմբերի, և յուրաքանչյուր ֆիզիկական ծավալ կարող է լինել միայն մեկ խմբում, իսկ խումբը կարող է տեղակայվել միանգամից մի քանի ֆիզիկական ծավալների վրա:
Իսկ տրամաբանական հատորները յուրաքանչյուրը մեկ խմբում են։

Բայց... անիծյալ, նորից 21-րդ դար է։ Իսկ սերվերները վիրտուալ են։ Անիմաստ է նրանց նկատմամբ կիրառել այն նույն մեխանիզմները, որոնք կիրառվել են ֆիզիկականի նկատմամբ։ Իսկ վիրտուալների համար կարևոր է տվյալներ ունենալ համակարգից առանձին։ Սա շատ կարևոր է, մասնավորապես, տվյալների արագ փոխանցման ունակության համար մեկ այլ վիրտուալ մեքենա (օրինակ, նոր ՕՀ-ին անցնելիս) և ընդհանրապես բոլոր տեսակի օգտակար բարիքների համար (օրինակ՝ հիպերվիզորի գործիքների օգտագործմամբ բաժանմունքներով կրկնօրինակումներ առանձին): . Հետևաբար, մեկ ծավալային խումբ օգտագործվում է համակարգի համար, իսկ մյուսը պարտադիր է տվյալների համար: Այս տրամաբանական բաժանումը շատ է օգնում կյանքում:

Եթե ​​վիրտուալ մեքենա ստեղծելիս ստեղծել եք միայն մեկ վիրտուալ կոշտ սկավառակ, ապա այստեղ ավարտվում է կազմաձևումը: Եվ եթե կան երկուսը, ապա պարզապես մի նշեք երկրորդը դեռ:

Սկսենք տեղադրումը:

Տեղադրումից հետո

Այսպիսով, նոր տեղադրված համակարգը վերջապես բեռնվեց: Առաջին բանը, որ դուք պետք է ստուգեք, ինտերնետն է:

ping ya.ru

Պատասխան կա՞։ - Հիանալի, սեղմեք Ctrl-C:
Եթե ​​ոչ, գնացեք ցանց ստեղծեք, առանց դրա կյանք չկա, բայց դա այն չէ, ինչի մասին է իմ հոդվածը:

Հիմա եթե մենք դեռ արմատի տակ չենք, անցեք արմատի տակ, քանի որ մուտքագրում է sudo-ով հրամանների քանակը անձամբ կոտրեց ինձ (և թող պարանոիդ ադմինները ներեն ինձ).

sudo -i

Այժմ առաջին բանը, որ մենք անում ենք, մուտքագրելն է

dnf -y update

Եվ եթե դուք կարդում եք այս հոդվածը 2019 թվականին, ամենայն հավանականությամբ, ոչինչ չի պատահի, բայց արժե փորձել։

Այժմ եկեք կազմաձևենք մնացած սկավառակը

Ասենք համակարգի հետ բաժանումը xvda էր, ապա տվյալների սկավառակը կլինի xvdb: ԼԱՎ.

Խորհուրդների մեծ մասը կսկսվի «Գործարկել fdisk-ը և ստեղծել բաժանում...»

Այսպիսով, սա է սխալ!

Ես նորից կասեմ, որովհետև դա շատ կարևոր է: Այս դեպքում աշխատել LVM-ի հետ, որը զբաղեցնում է մեկ ամբողջ վիրտուալ սկավառակ, դրա վրա միջնորմներ ստեղծելը վնասակար է։ Այս արտահայտության յուրաքանչյուր բառ կարևոր է: Եթե ​​մենք աշխատում ենք առանց LVM-ի, ապա պետք է: Եթե ​​մենք ունենք համակարգ և տվյալներ սկավառակի վրա, դա մեզ անհրաժեշտ է: Եթե ​​ինչ-ինչ պատճառներով մեզ պետք է սկավառակի կեսը դատարկ թողնել, մենք նույնպես պետք է: Բայց սովորաբար այս բոլոր ենթադրությունները զուտ տեսական են: Որովհետև եթե մենք որոշենք տարածք ավելացնել գոյություն ունեցող բաժանմանը, ապա դա անելու ամենահեշտ ձևն այս կոնֆիգուրացիան է: Եվ կառավարման հեշտությունն այնքան գերակշռում է շատ այլ բաների, որ մենք նպատակաուղղված շարժվում ենք դեպի այս կոնֆիգուրացիա:

Եվ հարմարությունն այն է, որ եթե ցանկանում եք ընդլայնել տվյալների բաժինը, դուք պարզապես բացատներ եք ավելացնում վիրտուալ բաժանմանը, այնուհետև ընդլայնում եք խումբը՝ օգտագործելով vgextend և վերջ: Հազվագյուտ դեպքերում կարող է այլ բան պահանջվել, բայց գոնե սկզբում ստիպված չեք լինի ընդլայնել տրամաբանական ծավալը, ինչն արդեն իսկ հաճելի է: Հակառակ դեպքում, հենց այս ծավալն ընդլայնելու համար խորհուրդ են տալիս սկզբում ջնջել եղածը, հետո նորը ստեղծել վերեւում... Ինչը այնքան էլ գեղեցիկ տեսք չունի և չի կարելի ուղիղ եթերում անել, բայց իմ նշած սցենարով ընդլայնում կարող է լինել. իրականացվել է «թռիչքի վրա»՝ առանց միջնորմն անգամ ապամոնտաժելու:

Այսպիսով, մենք ստեղծում ենք ֆիզիկական ծավալ, այնուհետև ծավալային խումբ, որը ներառում է այն, և ապա բաժանում մեր սերվերի համար.

pvcreate /dev/xvdb
vgcreate data /dev/xvdb
lvcreate -n www -L40G data
mke2fs -t ext4 /dev/mapper/data-www

Այստեղ «L» մեծատառի փոխարեն (և չափը ԳԲ-ով) կարող եք նշել փոքրը, այնուհետև բացարձակ չափի փոխարեն նշել հարաբերականը, օրինակ՝ օգտագործելու ներկայիս ազատ տարածության կեսը: ծավալային խումբ, դուք պետք է նշեք «-l +50% FREE»

Իսկ վերջին հրամանը ֆորմատավորում է միջնորմը ext4 ֆայլային համակարգում (որը մինչ այժմ, իմ փորձով, ցույց է տալիս ամենամեծ կայունությունը ամեն ինչ կոտրվելու դեպքում, ուստի ես նախընտրում եմ դա):

Այժմ մենք տեղադրում ենք միջնորմը ճիշտ տեղում: Դա անելու համար ավելացրեք ճիշտ տողը /etc/fstab:

/dev/mapper/data-www    /var/www                ext4    defaults        1 2

Եվ մենք հավաքում ենք

mount /var/www

Եթե ​​սխալ է տեղի ունենում, ահազանգեք: Քանի որ սա նշանակում է, որ մենք ունենք սխալ /etc/fstab-ում: Եվ որ հաջորդ վերագործարկման ժամանակ մենք շատ մեծ խնդիրներ կունենանք։ Համակարգը կարող է ընդհանրապես չբեռնվել, ինչը հաճախ շատ տխուր է ամպային ծառայությունների համար: Ուստի անհրաժեշտ է կա՛մ շտապ ուղղել ավելացված վերջին տողը, կա՛մ ընդհանրապես ջնջել։ Ահա թե ինչու մենք ձեռքով չգրեցինք mount հրամանը, այդ դեպքում մենք նման հիանալի հնարավորություն չէինք ունենա անմիջապես ստուգելու կազմաձևը:

Այժմ մենք իրականում տեղադրում ենք այն ամենը, ինչ ցանկանում էինք և բացում պորտերը համացանցի համար.

dnf groupinstall "Development Tools"
dnf -y install httpd @nodejs @redis php
firewall-cmd --add-service http --permanent
firewall-cmd --add-service https --permanent

Ցանկության դեպքում կարող եք նաև տվյալների բազա տեղադրել այստեղ, բայց անձամբ ես փորձում եմ այն ​​առանձին պահել վեբ սերվերից։ Թեև նրան մոտ պահելն ավելի արագ է, այո: Վիրտուալ ցանցային ադապտերների արագությունը սովորաբար մոտավորապես գիգաբիթ է, և նույն մեքենայի վրա աշխատելիս զանգերը տեղի են ունենում գրեթե ակնթարթորեն: Բայց դա ավելի քիչ անվտանգ է: ում համար ի՞նչն է ավելի կարևոր։

Այժմ մենք պարամետրը ավելացնում ենք կազմաձևման ֆայլին (մենք ստեղծում ենք նորը, CentOS-ի ժամանակակից գաղափարախոսությունն այսպիսին է)

echo "vm.overcommit_memory = 1"> /etc/sysctl.d/98-sysctl.conf

Վերագործարկեք սերվերը:
Մեկնաբանություններում ինձ նախատեցին, որ խորհուրդ էի տվել անջատել SeLinux-ը, այնպես որ ես կուղղվեմ և կգրեմ այն ​​մասին, որ սրանից հետո պետք է հիշել կարգավորել SeLinux-ը։
Իրականում, շահույթ! 🙂

Source: www.habr.com

Добавить комментарий