Serverissä pyörii i5-10500, eli 6c 12t ja 16gb ram alustavsti, 256 SSD, lisälevyjä voi lyödä sitten tarpeen mukaan tod. näk eli uskoisin että tehot riittävät myös kunnon virtualisointiin. Tuo kontin käyttö, ilmeisesti dockerista puhutaan, lienee järkevin tapa aloittaa kuitenkin vaikka debian/ubutun kanssa että pääsee tosiaan alkuun tuon linux maailman kanssa, ei proxmoxikaan ihan mahdottomalta vaikuttanut parin tutorial videon perusteella mutta haitat taivat vielä ylittää hyödyt.
No en nyt ole ollenkaan varma että on se järkevin vaihtoehto. Noita juttuja joita luettelit voi suurinta osaa ellei peräti kaikkia ajella konttina. Virtualisointi on mielestäni aika järeän luokan toimenpide joka myös monimutkaistaa ylläpitoa jos aletaan virtuaali pömpeliä laittamaan jokaiselle pulikalle omaansa.
Sen virtualisoinnin ainut etu on se että voit helposti sen kikottimen viskata myöhemmin toiseen koneeseen pyörimään jos sattuu nälkä kasvamaan syödessä ja niitä fyysisiä koneita alkaakin ilmestyä lisää.
Pitää kuitenkin ottaa huomioon että jokainen pystytetty virtuaalikone syö resursseja vaikka olisi shared memory käytössä.
Resurssien kannaltahan tuo virtuaalikonemaailma ei ole ihan tehokkainta resurssien käyttöä mutta mielestäni se on huomattavasti helpompi oppia ja ymmärtää kuin konttien / dockerin / vastaavien ymmärtäminen ja opettelu. Kyllähän virtuaalikoneiden kanssa menee pirusti muistia ja levytilaa hukkaan kun käyttöjärjestelmät syövät saman asian moneen kertaan.
Itse ainakin opin hetkessä virtuaalikoneiden maailman mutta noiden konttien kanssa on vielä paljon opeteltavaa kun konttien luonti, konttien väliset verkot, konttien ulkopuoliset tiedostot sun muut asiat eivät ole ihan itsestäänselviä asioita ainakaan itselleni. Virtuaalikoneiden puolellahan virtuaalikone on ihan kuin oikea tietokone, se vaan on toisen tietokoneen "sisällä" ja ne toimivat ihan kuin erillinen tietokonekin.
Resurssien kannaltahan tuo virtuaalikonemaailma ei ole ihan tehokkainta resurssien käyttöä mutta mielestäni se on huomattavasti helpompi oppia ja ymmärtää kuin konttien / dockerin / vastaavien ymmärtäminen ja opettelu. Kyllähän virtuaalikoneiden kanssa menee pirusti muistia ja levytilaa hukkaan kun käyttöjärjestelmät syövät saman asian moneen kertaan.
Itse ainakin opin hetkessä virtuaalikoneiden maailman mutta noiden konttien kanssa on vielä paljon opeteltavaa kun konttien luonti, konttien väliset verkot, konttien ulkopuoliset tiedostot sun muut asiat eivät ole ihan itsestäänselviä asioita ainakaan itselleni. Virtuaalikoneiden puolellahan virtuaalikone on ihan kuin oikea tietokone, se vaan on toisen tietokoneen "sisällä" ja ne toimivat ihan kuin erillinen tietokonekin.
Mä tykästyin cloud-inittiin (jonka sitten lopulta disabloin, kun vm kunnossa), kun se hoitaa dokumentoinnin siinä samalla (kun pitää ne konffifilut ja loitsut vaikka gitissä). Lisäksi saa aika minimaalisia vm:iä pyörimään.
Mä tykästyin cloud-inittiin (jonka sitten lopulta disabloin, kun vm kunnossa), kun se hoitaa dokumentoinnin siinä samalla (kun pitää ne konffifilut ja loitsut vaikka gitissä). Lisäksi saa aika minimaalisia vm:iä pyörimään.
Proxmox on ihan hyvä vaihtoehto ja helppo asentaa. Netistä löytyy paljon ohjeita sekä videoita ihan asennuksesta sitten laajempaan konfigurointiin.
Itsellä pyörii kone Proxmoxilla, jossa pääosin ajan sitten LXC containeria, jossa pyörii sitten tarvittavat "homelab" jutut. Proxmoxissa hyvä että voit luoda vaikka erillisen VM:n tietylle asialla ja sitten vaikka LXC:n hieman kevyimmille (kuten docker jne) jutuille.
Itse proxmoxin käyttöön ei hirveästi peruskäytössä terminaalia tarvita, pitkälti kaiken voi tehdä web-käyttöliittymän kautta.
Dockeria suositellaan ajettavaksi VM:ssä LXC:n sijaan. Keskusteluja tästä aiheesta on netti pullollaan, mutta myös Proxmoxin dokumentaatiossa sanotaan:
If you want to run application containers, for example, Docker images, it is recommended that you run them inside a Proxmox QEMU VM. This will give you all the advantages of application containerization, while also providing the benefits that VMs offer, such as strong isolation from the host and the ability to live-migrate, which otherwise isn’t possible with containers.
Dockeria suositellaan ajettavaksi VM:ssä LXC:n sijaan. Keskusteluja tästä aiheesta on netti pullollaan, mutta myös Proxmoxin dokumentaatiossa sanotaan:
Tarkoittaako tämä ohje nyt että pitäisi ottaa se container image ja ajaakin sitä virtuaalikoneena, vai pistää containerit ajoon virtuaalikoneen sisälle? Molemmin päin kuulostaa kohtalaisen älyttömältä suositukselta...
Yleensä niitä containereita ajetaan kun haetaan kevyempää virtualisointia eikä kaivata täyden virtuaalikoneen overheadia yms. "etuja".
Dockeria suositellaan ajettavaksi VM:ssä LXC:n sijaan. Keskusteluja tästä aiheesta on netti pullollaan, mutta myös Proxmoxin dokumentaatiossa sanotaan:
Ensinnäkin tuossa on vielä itselle sellainen ongelma, että kun serverissä ei ole kuin erillinen gpu (intel arc) niin sen joutuisi luovuttamaan yhdelle VM:lle että saa käytettyä esim Jellyfinin/Plexin kanssa. Sitten ei olisikaan enää GPU:ta käytettäväksi muille kun tuo yksi VM söisi sen kokonaan.
Ajan mielummin unpriviledged LXC:ssä ja annan tarvittavat oikat että kontti pääsee käsiksi näyttikseen.
En nyt suoraan näe että VM olisi tässä mitenkään enemmän turvallisempi.
Rupesinpa päivittämään vuosia toiminutta Linux-palvelinta Debian Stretchistä Busteriin (ja siitä tuoreempiin), kun sen joutui muista syistä boottaamaan. Tässäpä nousi tie pystyyn 'apt full-upgrade':ssa:
Koodi:
# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
dh-python emacs24-nox libboost-iostreams1.67.0 libboost-system1.67.0 libcwidget3v5 liblockfile1
libpython3.5-minimal libpython3.5-stdlib libsigc++-2.0-0v5 libssl1.0.2 libxapian30 python3-distutils
python3-lib2to3 python3.5 python3.5-minimal
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
apt apt-utils aptitude libapt-inst2.0 libapt-pkg5.0 libcurl3 tasksel tasksel-data
The following NEW packages will be installed:
libcurl4 libpython3.7-minimal libpython3.7-stdlib python3-distutils python3-lib2to3 python3.7
python3.7-minimal
The following packages have been kept back:
dmeventd
The following packages will be upgraded:
curl dash dpkg libpython3-stdlib libudev1 python3 python3-minimal udev
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
apt libapt-pkg5.0 (due to apt)
8 upgraded, 7 newly installed, 8 to remove and 2 not upgraded.
Need to get 9,074 kB of archives.
After this operation, 11.7 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?] no
Abort.
Tämä siis haluaisi poistaa apt:n mikä ei vaikuta hyvältä ajatukselta.
Koodi:
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
apt libapt-pkg5.0 (due to apt)
Jos yrittää asentaa erikseen apt:n (apt install apt):
Koodi:
The following packages have unmet dependencies:
apt : Depends: libapt-pkg5.0 (>= 1.7.0~alpha3~) but 1.4.11 is to be installed
E: Unable to correct problems, you have held broken packages.
ja sama libapt-pkg5.0:lle
Koodi:
The following packages have unmet dependencies:
libapt-pkg5.0 : Depends: libsystemd0 (>= 221) but 215-17+deb8u4 is to be installed
E: Unable to correct problems, you have held broken packages.
Miten tätä olisi parasta ruveta ratkomaan? Ei oikein arvaisi lähteä boottaamaan päivityksen ollessa kesken.
Rupesinpa päivittämään vuosia toiminutta Linux-palvelinta Debian Stretchistä Busteriin (ja siitä tuoreempiin), kun sen joutui muista syistä boottaamaan. Tässäpä nousi tie pystyyn 'apt full-upgrade':ssa:
Koodi:
# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
dh-python emacs24-nox libboost-iostreams1.67.0 libboost-system1.67.0 libcwidget3v5 liblockfile1
libpython3.5-minimal libpython3.5-stdlib libsigc++-2.0-0v5 libssl1.0.2 libxapian30 python3-distutils
python3-lib2to3 python3.5 python3.5-minimal
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
apt apt-utils aptitude libapt-inst2.0 libapt-pkg5.0 libcurl3 tasksel tasksel-data
The following NEW packages will be installed:
libcurl4 libpython3.7-minimal libpython3.7-stdlib python3-distutils python3-lib2to3 python3.7
python3.7-minimal
The following packages have been kept back:
dmeventd
The following packages will be upgraded:
curl dash dpkg libpython3-stdlib libudev1 python3 python3-minimal udev
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
apt libapt-pkg5.0 (due to apt)
8 upgraded, 7 newly installed, 8 to remove and 2 not upgraded.
Need to get 9,074 kB of archives.
After this operation, 11.7 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?] no
Abort.
Tämä siis haluaisi poistaa apt:n mikä ei vaikuta hyvältä ajatukselta.
Koodi:
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
apt libapt-pkg5.0 (due to apt)
Jos yrittää asentaa erikseen apt:n (apt install apt):
Koodi:
The following packages have unmet dependencies:
apt : Depends: libapt-pkg5.0 (>= 1.7.0~alpha3~) but 1.4.11 is to be installed
E: Unable to correct problems, you have held broken packages.
ja sama libapt-pkg5.0:lle
Koodi:
The following packages have unmet dependencies:
libapt-pkg5.0 : Depends: libsystemd0 (>= 221) but 215-17+deb8u4 is to be installed
E: Unable to correct problems, you have held broken packages.
Miten tätä olisi parasta ruveta ratkomaan? Ei oikein arvaisi lähteä boottaamaan päivityksen ollessa kesken.
Näistä tein update:n ja upgrade:n mutta en dist-upgrade:a. En tehnyt autoremove:a, koska mitään ei ollut roikkumassa. Missään komennoissa ei ole -y:tä.
apt upgrade oli ilman --without-new-pkgs, ja se asentelikin melkoisen määrän paketteja.
Onkohan merkitystä, mutta kone oli alunperin Debian Jessie ja päivitetty siitä aiemmin Stretch:ksi. Kyse on virtuaalipalvelimesta jossain Saksassa, joten olisi hyvä jos asennuksen saisi korjattua ilman uudelleenasennusta.
Näistä tein update:n ja upgrade:n mutta en dist-upgrade:a. En tehnyt autoremove:a, koska mitään ei ollut roikkumassa. Missään komennoissa ei ole -y:tä.
Tuli bootattua pariinkin kertaan ja päivitettyä sources.list osoittamaan archive.debian.org
apt upgrade oli ilman --without-new-pkgs, ja se asentelikin melkoisen määrän paketteja.
Onkohan merkitystä, mutta kone oli alunperin Debian Jessie ja päivitetty siitä aiemmin Stretch:ksi. Kyse on virtuaalipalvelimesta jossain Saksassa, joten olisi hyvä jos asennuksen saisi korjattua ilman uudelleenasennusta.
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
Jotain ongelmia saattaa tulla vastaan jos on jättänyt päivittämättä pitkäksi aikaa ja on käyttänyt siis tukematonta versiota distrosta ja sitä koittaa päivittää seuraavaan versioon tai ehkä rolling releasillakin voi tulla ongelmia tuossa tapauksessa.
Minusta tätä upgrade mahdollisuutta rummutetaan aika paljon liikaa verrattuna siihen että ongelmia vaikuttaa näkyvän aika paljon.
Voisi sitä joskus kuitenkin kokeilla itsekkin ja silloin koe-eläimeksi voisi hyvin valita jonkun virtuaalipalvelimen koska snapshotin kun ottaa ennen päivitystä niin epäonnistuminen ei ole mikään ongelma kun vaan palauttaa snapshotin ja mitään ei ole menetetty.
Itse asensin Kubuntun uuteen työpöytäkoneeseen 2015 ja sitä olen päivitellyt siitä asti uuteen versioon. Jotain joskus hajoaa, ei siis päivityksen kesken, vaan joku ei asia ei toimikaan enää uudessa versiossa, mahdollisesti tuon pitkään jatkuneen päivittelyn takia, kun ei sellaista varmaan testata. Ja kloonaan levystä aina kopion ennen asennusta jos tulee suurempaa häikkää. Mutta kaikenlaista säätöä on homen ulkopuolellakin, niin ei kiinnosta uusi päivitys. Toki noi muutokset voisi pitää gitissä ja home omalla osiollaan, niin noinkin uuden version kokonaan uudelleen asennus olisi varmaan aika vaivaton homma.
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
Näin se on, tämäkin on asennettu kai v. 2016 ja kerran päivitetty Jessie->Stretch. Boottaamaankin joutuu yhtenään, nytkin oli uptime vain yli 900 päivää. Tätä boottia tosin ei oikein voi pistää Linuxin piikkiin, koska kone piti ajaa alas virtualisointialustan lahottua ajan myötä.
Hätäilyä tämä versiopäivityskin oli, jatkettu tuki Stretch:lle jatkuu vielä kesään 2027 saakka:
Se, että jatkettu tuki on olemassa kertoo siitä, että versiopäivitykset eivät aina ole ongelmattomia. Samasta varoittaa myös Debian itse Release Noteissa.
Toisaalta ongelmien näkyminen on myös osittain harhaa: kukapa onnistuneista päivityksistä mihinkään kirjoittaisi.
Eikä ongelma ole pelkästään siinä, että se versiopäivitys saattaa mennä pieleen. Saattaa siinä se oma sovellus myös hajota, kun softat päivittyy.
Siksi kait on suhteellisen yleistä, että ei rikota sitä mikä toimii. Sitten kerran kymmeneen vuoteen asennellaan uusiksi. Jos palvelinta ajelee omalla raudalla, niin onhan se kymmenen vuoden jälkeen ihan asiallista päivittää rautakin samalla. Virtuaalikoneessa on sitten vieläkin helpompaa asennella se uusi versio uuteen instanssiin ja vaihtaa se tuotantoon kun on testattu toimivaksi.
