Haluaisin jakaa joitakin vaikutelmia sellaisen asian tarpeellisuudesta tai tarpeettomuudesta kuin ohjauspaneeli kaupalliseen yhden palvelimen verkkoprojektiin hyvin osa-aikaisen järjestelmänvalvojan kanssa. Tarina alkoi pari vuotta sitten, kun ystävien ystävät pyysivät minua auttamaan yrityksen - uutissivuston - hankinnassa teknisestä näkökulmasta. Oli tarpeen syventyä hieman siihen, mikä työskenteli minkä parissa, varmistaa, että kaikki tarvittavat yksityiskohdat siirrettiin oikeassa muodossa ja volyymissa, ja strategisesti keksiä, mitä voitaisiin parantaa.
Kauppa tehtiin, viulistia ei enää tarvittu. Loppu. Ei oikeastaan.
Sivusto toimi kaksiytimisessä 4 Gt:n virtuaalikoneessa Linodessa, jossain sammaleisessa Debian5:ssä, jonka käyttöaika oli 400 päivää ja sellainen luettelo päivittämättömistä paketeista. Web-osa itse kirjoitetussa CMS:ssä, nginx, php5.3 FPM, mysql viritetty Percona. Periaatteessa se toimi.
Samanaikaisesti kanssani käytyjen keskustelujen kanssa uusi omistaja etsi ohjelmoijaa saattamaan projektin odotuksiin. Löytyi. Ohjelmoija arvioi liikenteen ja volyymit ja päätti osaavansa optimoida ja hallita kustannuksia. Hän siirsi koko sivuston 700 ruplan jaettuun isännöintiin, jota hallinnoi tavallinen IS****er. Muutamaa päivää myöhemmin omistajalta tuli toinen soitto: "Kaikki on hidasta ja näyttää siltä, että olemme rikki." Yritin korjata tilannetta paneelin kautta, mutta jonkin ajan turhien yritysten jälkeen vaihtaa PHP-versiota tai käsittelijää fcgi:stä fpm:ksi, luovutin ja menin kuoreen. Sieltä löysin käytössä olevan virheenkorjauksen, joka loisti koko Internetissä lihaksen salasanalla, 777 joistakin kansioista, jotka siihen mennessä olivat murtuneet haittaohjelmista ja vastaavista hölynpölyistä. Omistaja tajusi ja päätti, että oli väärin säästää isännöinnistä, ohjelmoijasta ja järjestelmänvalvojasta, joka pystyi seuraamaan asioiden etenemistä.
Olemme menossa RuVDS:ään. Hieman lähempänä kuin brittiläinen Linode, ja jos yhtäkkiä haluat tallentaa henkilötietoja ja kaikkea tätä, sinun ei tarvitse muuttaa minnekään muualle. Koska projektia oli tarkoitus laajentaa, otimme kasvuun virtuaalikoneen: 4 ydintä, 8 gigatavua muistia, 80 Gt levyä. Kyse ei ole siitä, ettenkö osaa määrittää nginx-konfiguraatioita manuaalisesti, minulla ei vain ollut innostusta työskennellä tämän projektin parissa niin tiiviisti (katso yllä osa-aikaisesta). Siksi asensin Pleskin (tässä jätän pois asennustiedot, koska niitä ei yleensä ole: käynnistin asennusohjelman, asetin järjestelmänvalvojan salasanan, kirjoitin avaimen - siinä kaikki), tuolloin se oli 17.0. Perusasetukset toimivat siedettävästi heti, kun käytössä on fail2ban sekä uusimmat saatavilla olevat versiot PHP:stä ja nginxistä.
Kannattaa varmaan pysähtyä ja selittää miksi. Koska teen tällaisia harvoin, eikä minulla ole erityisiä työkaluja tai valmisteluja jokaiseen tapaukseen, oli selvää, että jonkinlainen perusasioiden automatisointi tarvitaan, jotta ensinnäkin nopeasti, toiseksi turvallisesti ja kolmanneksi , kaikki parhaat käytännöt, jotka joku on jo ottanut sen käyttöön.
Joten asensin sen. Säästin paljon aikaa, sivuston uudelleenkäynnistys uudella palvelimella oli melkein välitöntä. Jäljelle jäi vain muokata lihaskonfiguraatiota antamalla sille puolet muistista ja lisäämällä puskurivarastojen määrää ja antamalla nginxille puolet ytimistä (Plesk ei koske globaaleihin konfiguraatioihin) ja mennä pariksi päiväksi kuoreen katsomaan. mysqltuner-tilastoissa. Kyllä, ja ostin maksullisen ImunifyAV:n laajennusluettelosta päästäkseni eroon tulvivista haittaohjelmista. Noin 11000 XNUMX tartunnan saanutta tiedostoa löydettiin. Kamalaa on se, että statiikkaan kaadettiin hämäriä koodinpätkiä, ja sen käsin puhdistaminen olisi ollut täysin tylsää. Ensin kokeilin ClamAV, mutta kuten kävi ilmi, se ei vaadi sellaisia asioita, mutta ImunifyAV voisi. Lisäksi desinfioidut tiedostot pysyvät toimintakunnossa; haittaohjelman sisältävä osa yksinkertaisesti poistetaan.
Aritmetiikka on yksinkertainen: 50 dollaria kuukaudessa VMkalle, 10 dollaria Pleskille (itse asiassa vähemmän, koska ostit sen vuodeksi kerralla kahden kuukauden alennuksella) ja 3 dollaria virustorjuntaan. Tai paljon rahaa aikaani, jonka olisin käyttänyt aluksi palvelimella haravoimalla näitä tallia manuaalisesti. Omistaja oli varsin tyytyväinen tähän järjestelyyn.
Sillä välin he löysivät uuden ohjelmoijan. Sovimme hänen kanssaan vastuunjaosta, loimme testiversiolle aliverkkotunnuksen ja työ alkoi. Hän leikkasi uutta versiota sivustosta Laravelissa, ja minä katsoin fail2ban%).
Mielenkiintoista on, että uteliaiden virta ei pysähdy ja kiellettyjen osoitteiden listalla on aina noin sata osoitetta. Vaikutus on mielenkiintoinen: varsinkin yleensä jos kirjaudun shelliin, näen tervehdyksessä noin 20000 30000-2 70 epäonnistunutta kirjautumisyritystä SSH:n kautta. Kun fail0ban on käytössä, noin 2. Panostukset: XNUMX. Valitettavasti se ei mennyt ilman pisaraa voidetta. Oletuksena WAF (modsecurity) oli puoliksi käytössä: etsintätilassa. Eli hän kirjoitti epäilyttävän toiminnan lokiin, mutta ei tehnyt mitään. Ja failXNUMXban luki umpimähkään kaikki lokit käytössä olevien vankiloiden mukaan ja tappoi kaiken, mikä liikkui. Niinpä me bannoimme puolet toimittajista :D. Minun piti poistaa tämä vankila käytöstä ja luetteloida tarvittavat IP-osoitteet luotettavuuden vuoksi. Ponnisteluja panostetaan: työnnä hiirtä kahdesti ja opeta toimittajat kertomaan IP-osoitteesi.
Ohjelmoija piti välittömästi mahdollisuudesta ladata tietokantoja suoraan paneeliin ja nopeasta pääsystä phpMyAdminiin
Pidin lokeista ja varmuuskopioista. Lokit kirjoitetaan ja kierretään ulos laatikosta; Varmuuskopiot on erittäin helppo tehdä. Hitaimmilla aikoina tehdään täysi varmuuskopio, noin 10 keikkaa, ja sitten joka päivä yksi, 200 megatavua kerrallaan, viikon ajan. Palautus on rakeista tiettyyn tiedostoon tai tietokantaan asti. Jos sinun on palautettava inkrementaalisesta, sinun ei tarvitse ensin vaivautua koko ketjun täydelliseen ja palauttamiseen, vaan Plesk tekee kaiken itse. Voit ladata varmuuskopioita missä tahansa: FTP:hen, dropboxiin, s3-sämpöön, google Driveen jne.
Päivä F: ohjelmoija sai vihdoin valmiiksi uuden moottorin, latasimme sen tuotantoon, toimme vanhat tiedot ja istuimme valitsemassa tulevan Maseratimme väriä. Istumme edelleen ja valitsemme.
Ensimmäiset ongelmat alkoivat. Uusi sivusto oli odotetusti raskaampi kuin vanha, mutta todellinen rake oli se, että liikenteen houkuttelemiseksi he käyttivät muun muassa Yandex.Zeniä, joka toi paljon vierailijoita. Sivusto kaatui 150 samanaikaisella yhteydellä (en puhu RPS:stä, koska he eivät mitanneet sitä). Aloimme painaa painikkeita ja kääntää nuppeja php_fpm-asetusalueella:
Hei, hänellä on jo 500 yhteyttä. Kun luottokortit lisättiin promootiovälineisiin, liikenteen aallot kasvoivat. Seuraava virstanpylväs on 1000 samanaikaista yhteyttä. Tässä meidän piti viimeistellä koodi ja tarkastella lihaksen sielua. Roiskeet eivät auttaneet, mutta emme todellakaan odottaneet sitä. Otimme käyttöön hitaan kyselylokin, lisäsimme indeksit tietokantaan, poistimme tarpeettomat kyselyt koodista ja siivosimme jälleen mysql-konfiguraation mysqltunerin ohjeiden mukaan.
Uusi haaste - 2000 yhteyttä. Plesk 17.8:n versio julkaistiin juuri, ja siihen lisättiin muun muassa nginx-välimuisti. Päivitetty (yllättävän helppoa). Kokeillaan. Toimii! Ja sitten he astuivat pehmeälle puolelle, Yandex.Zen-syöte lakkasi toimimasta. Sivusto toimii, syöte ei toimi. Syöttö ei toimi, liikennettä ei ole. Ilmapiiri lämpenee. Olosuhteiden ja mielikuvituksen puutteen painostamana menin välittömästi straceen ja nginxiin ja löysin etsimäni. Osoittautuu, että jossain vaiheessa tyhmä nginx välimuistiin hajallaan olevan 500. virheen vastauksena Yandex get feed.xml. Korjattiin se lisäämällä poikkeuksia välimuistin asetuksiin:
On selvää, että omistaja tarvitsee LISÄÄ, aallot kasvavat hitaasti. Toistaiseksi pärjäämme, mutta aloimme kokeilemaan memcachediä etukäteen, onneksi Laravel tukee sitä melkein laatikosta pois. En jotenkin halunnut asentaa memcachedia manuaalisesti "pelatakseni", joten asensin telakointikuvan. Suoraan paneelista.
No, okei, valehtelen, minun piti mennä kuoreen ja asentaa moduuli peclillä. Juuri näin . Suorituksen kasvusta ei ole vielä sanottavaa, tuloja ei ole ollut tarpeeksi suuria. Sivustomoottori on kytketty localhost:11211:een, tilastot näytetään, muistia kuluu. Jos pidät siitä, katsotaan mitä tehdään seuraavaksi. Joko jätämme sen niin, tai asetamme "todellisen" akselille. Tai kokeillaan redisiä samalla tavalla
Sitten piti liittää postituslista. Ei releitä, vain smtp-todennus. Asetan sähköpostiosoitteen ja käytän sen tietoja uutiskirjeen lähettämiseen PHP:n kautta.
Ei kauan sitten Plesk Obsidian (18.0) julkaistiin, päivitimme aiempien kokemusten perusteella ilman pelkoa. Kaikki sujui hyvin, ei edes puhuttavaa. Miellyttävä asia on, että käyttöliittymän laatu on parantunut huomattavasti, siitä on tullut nykyaikaisempi ja paikoin kätevämpi. Hieno juttu, edistynyt valvonta Grafanassa.
En ole vielä käsitellyt sitä yksityiskohtaisesti, mutta voit esimerkiksi asettaa hälytyksiä mille tahansa parametrille sähköpostiisi. Omistajalle, lol.
Vaikka puhun käyttöliittymästä, se on herkkä ja toimii todella hyvin puhelimessa. Alkuvaiheessa, kun yritimme löytää optimaaliset asetukset PHP:lle ja muille asioille, tämä auttoi paljon. Ja varsinkin kun ohjelmoija työinnostuskohdassa tekee jotain kello 23:XNUMX, ja minä juon työinnostuksessa vodkaa kylpylässä, ja minun on KIELTÄ VÄLINEN vaihdettava jotain.
Oh, muuten. Kuvassa näkyy, että PHP Composer on ilmestynyt. Emme ole vielä pelanneet sillä, mutta esimerkiksi Laravelille se voi säästää pari shell-kirjautumista ja jonkin verran aikaa riippuvuuksien asentamiseen. Sama järjestelmä on olemassa Node.JS:lle ja Rubylle.
SSL:llä kaikki on yksinkertaista. Jos verkkotunnus ratkeaa odotetusti, Let's Encrypt tehdään yhdellä napsautuksella ja päivittää sitten itsensä sekä itse verkkotunnukselle että aliverkkotunnuksille ja jopa sähköpostipalveluille.
Plesk itse ohjelmistona on tällä hetkellä varsin miellyttävä ja vakaa. Se päivittää itsensä ja akselin hiljaa, kuluttaa vähän resursseja ja toimii sujuvasti. En edes muista, että olisin jossain astunut johonkin, mikä olisi ollut ilmeinen vika tuotteessa. Ongelmia tietysti oli, mutta ne johtuivat joko epätäydellisestä kokoonpanosta tai jostain risteyksestä, joten ei ole mitään valittamista. Vaikutelmat Pleskin kanssa työskentelystä ovat yleensä miellyttäviä. Mitä sillä ei ole, ja meidän on ymmärrettävä tämä, on mikä tahansa (kaikki) klusterit. Ei LB eikä HA. Voit yrittää, mutta siihen liittyy niin paljon työtä, että on parempi tehdä jotain toisin alusta alkaen.
Luulen, että voimme tiivistää sen. Tapaukseen, jossa ylläpitäjää ei ole tai häntä ei ole tarpeeksi, kun isännöinnin ja sillä pyörivien sivustojen hinta ylittää, vaikkapa 100 USD, kun ei puhuta 1500:n eläinjaosta. sivustoja palvelimella, kun päätöksentekijä joutuu kohtaamaan Jos sinulla on valinnanvaraa palkata osa-aikainen ylläpitäjä tai ostaa ohjelmisto ja saada ylläpitäjä puolikkaalla taalalla vai ei ollenkaan - se on ehdottomasti järkevää. Etäjärjestelmänvalvojan näkökulmasta - sama asia. 10 dollaria kuukaudessa ja säästää aikaa ja antaa joustavuutta työhön erittäin pitkäksi ajaksiоsuurempi määrä. Jos esimerkiksi minua pyydetään voimakkaasti ottamaan siipikseni vastaava projekti, vaadin sen siirtämistä Pleskiin.
Lähde: will.com