Bevezető
Már két napja megjelent az új CentOS operációs rendszer verziója, nevezetesen a CentOS 8. Jelenleg az interneten meglehetősen kevés cikk található arról, hogy ebben hogyan lehet valamit csinálni, ezért úgy döntöttem, hogy kitöltöm ezt a hiányt. Ami a legfontosabb, hogy nemcsak arról fogok mesélni, hogyan telepítsek néhány programot, hanem arról is, hogyan látom a Linux telepítését virtuális környezetben a mai világban a tipikus feladatokhoz, beleértve a lemezek felosztását és másokat.
De először szeretnék röviden mesélni arról, miért érdemes áttérni erre a verzióra az összes korábbi verzióról, aminek két oka is van:
- php7! Az előző CentOS verzió alatt a 'hagyományos' php5.4 volt telepítve...
Rendben, ha egy kicsit komolyabbak vagyunk, akkor nagyon sok csomag átugrott egynél több verziót is. Mi (a redhat-os rendszerek kedvelői) végre belépünk, ha nem is a jövőbe, de legalább a jelenbe. Az Ubuntu hívei már nem fognak nevetni rajtunk és ujjukkal mutogatni ránk, nos... legalább egy ideig ;).
- Áttérés a yum-ról a dnf-re. A fő különbség az, hogy mostantól hivatalosan is támogatott több csomagverzióval való munkavégzés. Eddig a nyolcas változatban még soha nem volt rá szükségem, de ígéretesen hangzik.
Virtuális gép létrehozása
A hipervizorok különbözőek, és nem célom az olvasót egy konkrétra kondicionálni, az általános elvekről fogok beszélni.
Memória
Első... A CentOS rendszer telepítéséhez a 7-es verziótól kezdődően biztosan, de szerintem a 6-osban is így volt ('de ez nem biztos'), szükséges minimum 2 GB RAM. Ezért javaslom, hogy először ennyit adjunk meg.
De ha úgy alakul, a telepítés után a memória mennyisége csökkenthető. 1 GB-on a rendszer teljesen normálisan működik, ezt kipróbáltam.
Lemez
A normális telepítéshez 20-30 GB méretű virtuális lemezt kell létrehozni. Ennyi elegendő a rendszernek. És egy második lemez az adatok számára. Ezt a virtuális gép létrehozásakor vagy utána hozzáadhatod. Én általában utólag adom hozzá.
Processzor
Egy magon a rendszer nem lassul le. Mivel az erőforrások szabadon skálázhatók, nem látom értelmét több erőforrást adni a telepítés során (kivéve, ha tökéletesen ismered az igényeket, és lusta vagy újra belépni a konfigurálóba).
A többi általában maradhat az alapértelmezett beállításoknál.
Tulajdonképpen a telepítés.
Nos, indul a telepítő... Én személy szerint már régóta csak virtuális gépként telepítem az ilyen szolgáltatásokat, így nem írom le, hogyan kell a rendszertöltő anyagokat pendrive-ra másolni — egyszerűen ISO-t csatolok CD-ként a kedvenc hipervizoromban, betöltés, és indulunk.
Az alap telepítés eléggé tipikus módon zajlik, csak néhány pontra fogok kitérni.
Forrás kiválasztása
A nyolcadik verzió megjelenése óta a Yandex tükrös változata már több napja le van állva. Nos, periódikusan újraindul, majd újra hibát mutat. Biztos vagyok benne, hogy a probléma a szolgáltatás túlterheltségében rejlik. Ezért nekem forrás megadásához nem volt elegendő a megszokott cím megadása, hanem kellett menném , hogy válasszak egy olyan tükröt, amelyik tetszik, és manuálisan kell megadnom a címet a telepítő ablakában. Itt fontos, hogy az útvonalat annak a mappának kell megadni, ahol a repodata. Például, .
Lemezfelosztás
Ez a kérdés inkább vallási jellegű a véleményem szerint. Minden adminisztrátornak megvan a saját véleménye ezzel kapcsolatban. De mégis megosztom a véleményemet a kérdésről.
Igen, elvileg az egész helyet fel lehet osztani a gyökérmappa számára, és általában működni fog, sok esetben pedig egészen jól is. De akkor minek is bonyolítani a dolgot különféle partíciókkal? — Az általam vélt két fő oka ennek: kvóták és hordozhatóság.
Például, ha valami rosszul sül el, és a fő partícióval kapcsolatosan adatokban hibák jelentkeznek, szeretném, ha még mindig lehetőségem lenne elindítani a rendszert és elvégezni a helyreállítási folyamatokat. Ezért személy szerint külön partíciót képezek a /boot számára. Itt található a kernel és a bootloader. Általában elég 500 MB, de ritkább esetekben több is szükséges lehet, figyelembe véve, hogy már megszoktuk, hogy helyet terabájtokban mérjünk, így 2 GB-ot osztok ki erre a partícióra. Itt fontos, hogy ezt nem szabad lvm-ként csinálni.
Ezután következik a rendszer gyökere. Normál telepítés során soha nem kellett több mint 4 GB a rendszernek, de tervezett események során gyakran használom a /tmp könyvtárat a disztribúciók kicsomagolására, így nincs értelme külön partíciót képezni neki — a modern rendszerek automatikusan ürítik, ezért nem telítődik. Így a gyökér számára 8 GB-ot osztok ki.
A swap... In practice, it is of little use. If your server is using swap, it simply means that the server needs more RAM. Otherwise, performance issues are guaranteed (or some program has memory leaks). Therefore, this section is only necessary for diagnostics. So 2 GB is a great figure. Yes, regardless of how much memory is on the server. Yes, I have read all those articles about the ratio of memory size to swap size... In my opinion, they are outdated. In 10 years of practice, I have never needed it. 15 years ago, I did use it, though.
Whether to allocate /home as a separate partition is something each person can decide for themselves. If someone will actively use this directory on the server, it’s better to allocate it. If no one will use it, there’s no need.
Next, /var. In my opinion, it should definitely be allocated. You can start with a figure of 4 GB, and then see how it goes. And yes, by 'how it goes,' I mean that
- firstly, you can always mount another disk in the /var subdirectory (which I will demonstrate later),
- secondly, we have LVM — we can always add more. Usually, this is necessary when too many logs start to accumulate there. However, I have never been able to predict this number in advance, so I start with 2 GB and then adjust.
Any unallocated space will remain free in the volume group, and it can always be used later.
LVM
Transzparens árak Partitions other than /boot should be made in LVM. Yes, including swap. Yes, swap should ideally be at the beginning of the disk, but in the case of LVM, its location cannot be determined. But as I mentioned earlier, your system nem kell does not need to use swap at all. Therefore, it doesn't matter where it is located. We are not living in 1995, honestly!
Next, there are several basic entities in LVM that you need to know how to work with:
- physical volume
- volume group
- logical volume
Physical volumes are combined into groups, where each physical volume can only be in one group, while a group can span multiple physical volumes.
Logical volumes are located within a single group.
De… Nekünk, a francba, ismét a 21. században vagyunk. És virtuális szerverek állnak rendelkezésre. Nincs értelme ugyanazokat a mechanizmusokat alkalmazni, amelyeket a fizikai szerverekre használtak. A virtuális környezeteknél fontos, hogy az adatok elkülönüljenek a rendszertől! Ez különösen fontos, ha gyorsan szeretnénk adatokat átkapcsolni egy másik virtuális gépre (például új operációs rendszerre váltáskor), és egyéb hasznos előnyöket lehet így elérni (például a hipervizor által támogatott elkülönített biztonsági mentéseket a partíciók alapján). Ezért az egyik volume groupot a rendszerhez és egy másikat az adatokhoz használjuk! Ez a logikai elkülönítés nagyban megkönnyíti az életet!
Ha létrehozta a virtuális gépet, és csak egy virtuális merevlemezt adott meg, akkor a konfiguráció itt meg is áll. Ha két merevlemezt hozott létre, akkor a második merevlemez még ne legyen kiosztva.
Indítjuk a telepítést.
Telepítés utáni
Na, végre betöltött a frissen telepített rendszer. Az első, amit ellenőrizni kell – az internetkapcsolat.
ping ya.ru Van válasz? – Remek, nyomjuk meg a Ctrl-C-t.
Ha nincs – állítsa be a hálózatot, nélkülözhetetlen a működéshez, de a cikkem nem erről szól.
Most, ha még nem vagyunk root felhasználó alatt, lépjünk be rootként, mert beírni ennyit parancsot sudo-val, számomra elég macera (és legyenek kedvesek a paranoid rendszergazdák):
sudo -iMost először is írjuk be
dnf -y updateÉs ha ezt a cikket 2019-ben olvassa, valószínűleg nem történik semmi, de megérte kipróbálni.
Most konfiguráljuk a maradék lemezt.
Tegyük fel, hogy a rendszerpartíciónk xvda volt, akkor az adatlemezt xvdb-nak nevezzük. Rendben.
A legtöbb tipp úgy kezdődik, hogy „Indítsa el az fdisk-et és hozza létre a partíciót…”
Nos, ez nem helyes.!
Még egyszer hangsúlyozom, mert ez fontos! Ilyen esetben, amikor LVM-mel dolgozunk, ami egy egész virtuális lemezt foglal el, nem szabad partíciókat létrehozni rajta! Ebben a mondatban minden szó fontos. Ha LVM nélkül dolgozunk – akkor szükséges. Ha a lemezen mondjuk a rendszer és az adatok vannak – akkor is szükséges. Ha valamilyen oknál fogva ki akarjuk hagyni a lemez felét –az is szükséges. De általában ezek a feltételezések szigorúan elméletiek. Mert ha bővíteni szeretnénk a meglévő partíciót, akkor ezt a legkönnyebb így megtenni. És az adminisztráció kényelme annyira felülmúlja a többit, hogy tudatosan tartunk ezen konfiguráció felé.
A kényelem abban rejlik, hogy ha bővíteni szeretné a tárolóterületet, egyszerűen hozzáadhat helyet a virtuális partícióhoz, majd a vgextend parancs segítségével bővítheti a csoportot, és kész is! Ritka esetekben szükség lehet valami másra, de legalább nem kell a logikai kötetet az elején bővíteni, ami már önmagában is kellemes. Ugyanis a kötet bővítéséhez gyakran ajánlják, hogy először töröljük a meglévőt, majd hozzunk létre egy újat a felszínen… ami nem túl vonzó és élő rendszer alatt nem hajtható végre, míg a fent említett forgatókönyv szerint a bővítés „út közben” is elvégezhető, még a partíció lecsatolása nélkül is.
Összegzésképpen létrehozunk egy fizikai kötetet, majd egy kötetcsoportot, amely tartalmazza, végül pedig egy partíciót a szerverünk számára:
pvcreate /dev/xvdb
vgcreate data /dev/xvdb
lvcreate -n www -L40G data
mke2fs -t ext4 /dev/mapper/data-www
Itt a nagy „L” (és GB méret) helyett megadhat egy kis „l”-t, és akkor az abszolút méret helyett relatív méretet használhat, például ha a kötetcsoportban lévő szabad hely felét szeretné használni, akkor „-l +50%FREE” -t kell megadnia.
Az utolsó parancs a partíciót ext4 fájlrendszerre formázza (amely a tapasztalataim szerint eddig a legstabilabb, ha valami elromlik, ezért én ezt preferálom).
Most csatlakoztatjuk a partíciót a szükséges helyre. Ehhez a megfelelő sort kell hozzáadnunk az /etc/fstab fájlhoz:
/dev/mapper/data-www /var/www ext4 defaults 1 2Majd beírjuk
mount /var/wwwHa hiba lép fel — riasztás! Mert ez azt jelenti, hogy hiba van az /etc/fstab fájlban. És a következő újraindításkor nagy problémáink lesznek. A rendszer talán nem is bootol el, ami a felhőszolgáltatások esetén gyakran nagyon szomorú. Ezért vagy sürgősen javítanunk kell az utoljára írt sort, vagy teljesen el kell távolítanunk! Ezért nem írtuk be a csatolási parancsot kézzel — akkor nem kaptuk volna meg ezt a nagyszerű lehetőséget, hogy azonnal ellenőrizzük a konfigurációt.
Most pedig telepítjük mindent, amit akartunk, és megnyitjuk a portokat a web számára:
dnf groupinstall "Development Tools"
dnf -y install httpd @nodejs @redis php
firewall-cmd --add-service http --permanent
firewall-cmd --add-service https --permanent
Igény esetén adatbázist is telepíthetünk ide, de személy szerint igyekszem azt külön a webszervertől tartani. Bár közel tartva gyorsabb, ez tény. A virtuális hálózati adapterek sebessége általában egy giga körül van, és ha ugyanazon a gépen dolgozunk, az elérések szinte azonnaliak. De cserében kevésbé biztonságos. Mindenkinek más az, ami fontosabb.
Most hozzáadjuk a paramétert a konfigurációs fájlhoz (újat hozunk létre, a CentOS modern ideológiája ezt kívánja)
echo "vm.overcommit_memory = 1" > /etc/sysctl.d/98-sysctl.conf Újraindítjuk a szervert.
A kommentekben megkritizáltak, amiért azt tanácsoltam, hogy kapcsoljam ki a SeLinux-ot, ezért most javítom a hibámat, és írok arról, hogy ezt követően ne felejtsük el beállítani a SeLinux-ot.
Tulajdonképpen, ez egy jó lehetőség! 🙂
Forrás: habr.com
