Päiväkirjan hakemistoDockup / kenttämuistio
Note / self-host-minio

MinIO:n itseisännöinti vuonna 2026: S3-endpointit, TLS ja kestävä tallennus

Käytännön opas MinIO:n itseisännöintiin: Docker, portit, pysyvä data, TLS, tietoturva, varmuuskopiot ja tuotantokäyttöä estävät ongelmat. Vaihe vaiheelta.

Epäonnistunut MinIO-käyttöönotto ei aina kaadu. Se saattaa näyttää kirjautumissivun, vaikka clientit allekirjoittavat pyynnöt Consolen URL-osoitteelle S3 API -URL-osoitteen sijaan. Aloita sen sijaan end-to-end-tarkistuksella: luo bucket, lataa multipart-objekti, nouda se presigned URL:n kautta ja varmista, että versionoidun poiston voi palauttaa.

Tarkistus vastaa MinIO:n dokumentoitua käyttötarkoitusta: S3-yhteensopivaa objektitallennusta hallitsemillasi levyillä. Se paljastaa puuttuvat riippuvuudet, väärät proxy-oletukset ja ephemeral-datan aikaisemmin kuin pelkkä uptime-probe.

Mihin MinIO perustuu

MinIO:n HTTP-prosessi kuuntelee porttia 9000; pidä portti sovellusverkossa ja julkaise vain alustan reitti. Paikallisen runtime-ympäristön vaatimus on toinen levy tai etäkohde palautettavia varmuuskopioita varten. Määritä sen elinkaari selkeästi, jotta MinIO:n siirtäminen hostilta toiselle ei muuta toimintaa huomaamatta.

Kirjaa rajapinta lyhyenä sopimuksena: kuka vastaa vaatimuksesta, mitä credentialia käytetään, mikä timeout on hyväksyttävä ja miten virhe näkyy. Suorita sitten tämä transaktio: luo bucket, lataa multipart-objekti, nouda se presigned URL:n kautta ja varmista, että versionoidun poiston voi palauttaa. Havainnoi ajon aikana levyn latenssia, samanaikaisia multipart-latauksia, vapaan tilan puskuria ja sovellusten sekä S3-endpointin välistä verkkokapasiteettia, sillä tämä workload antaa käyttökelpoisemman lähtökohdan mitoitukselle kuin idle-container.

Docker-perusta MinIO:lle

Tuotantokäyttöä muistuttava käynnistys on tarkoituksella yksinkertainen: nimetty tila, eksplisiittinen portti eikä imageen tallennettua secrettiä.

docker run -d \
  --name minio \
  --restart unless-stopped \
  -p 127.0.0.1:9000:9000 \
  -p 127.0.0.1:9001:9001 \
  -v minio-data:/data \
  -e MINIO_ROOT_PASSWORD=replace-with-a-long-random-value \
  -e MINIO_ROOT_USER=dockup-admin \
  quay.io/minio/minio:latest server /data --console-address :9001

Esimerkki on perusta, ei täydellinen tukipino. Vahvista paikallinen vaatimus ennen julkaisua: toinen levy tai etäkohde palautettavia varmuuskopioita varten. Tarkista käytössä olevat mountit ja kuuntelija, kokeile sitten bucketin luomista, multipart-objektin lataamista, objektin noutamista presigned URL:n kautta ja varmista, että versionoidun poiston voi palauttaa. Pinnaa toimiva image ennen seuraavaa uudelleenkäynnistystä.

Domainit, proxy-headerit ja portti 9000

TLS:n käyttöönotto on vain puolet MinIO-reitistä. Reititä S3 API ja Console erillisiin hostnameihin, kun molemmat julkaistaan. Ohjaa liikenne sisäisesti porttiin 9000 ja välitä ulkoinen scheme, jotta generoidut URL-osoitteet ja secure cookiet pysyvät yhdenmukaisina.

Suorita MinIO:n koko käyttötapaus puhtaasta verkosta, älä vain juurisivun tarkistusta. 502- tai sertifikaattivirhe voidaan rajata automaattisella domain- ja TLS-asetuksella. Jos liikenne saavuttaa prosessin ja clientit allekirjoittavat pyynnöt Consolen URL-osoitteelle S3 API -URL-osoitteen sijaan, selvitä ongelma siinä kohdassa, jossa se tapahtuu, äläkä kasaa uudelleenohjauksia toistensa päälle.

Suunnittele MinIO-palautus ennen käynnistystä

Tee MinIO:lle palautusmanifesti: bucket-data, policyt, userit ja testatut objektitason replikat. Mounttaa /data ennen bootstrapia, kirjoita vaaratonta esimerkkidataa ja vaihda container varmistaaksesi, että polku todella säilyy. Tarkista omistajuus ja vapaa tila nyt, sillä mountattu mutta kirjoitussuojattu polku toimii käytännössä aivan kuin persistence puuttuisi.

Varmuuskopioi käynnissä olevasta serveristä erilliseen failure domainiin. Luo MinIO uudelleen pinnatusta imagesta ja varmista, että bucket-versiot, policyt, userit ja edustava multipart-objekti säilyvät palautuksessa eri tallennustilaan. Persistent volume -opas auttaa muuttamaan harjoituksen snapshot- ja retention-policyksi.

Valitse MinIO:n trust boundary

Tee threat model MinIO:n suorittamasta toiminnosta, älä vain sen kirjautumislomakkeesta. Tässä suuri riski on lyhyiden oletusarvoisten root-credentialien käyttäminen tai admin Consolen laaja julkaiseminen. Toteuta seuraava rajaus: erota S3 API hallinnollisesta Consolesta ja luo application keyt, joilla ei voi hallita koko serveriä.

Käsittele MINIO_ROOT_PASSWORD-arvoa sen MinIO-roolin mukaisesti: pidä sensitiiviset arvot poissa Gitistä, dokumentoi rotaation vaikutukset äläkä koskaan korvaa tuotantoarvoa julkisella esimerkillä. Älä ratkaise permission-virhettä ajamalla containeria root-käyttäjänä tai mounttaamalla hostia laajasti. Resurssirajat kuuluvat myös security designiin, kun käyttäjät voivat aiheuttaa levyn latenssia, samanaikaisia multipart-latauksia, vapaan tilan puskurin kulumista ja liikennettä sovellusten sekä S3-endpointin välillä.

Lokit, jotka vastaavat seuraavaan kysymykseen

Havainnoi MinIO:n suorittamaa työtä: levyn latenssia, samanaikaisia multipart-latauksia, vapaan tilan puskuria ja sovellusten sekä S3-endpointin välistä verkkokapasiteettia. Aseta rajat niin, että tälle työlle jää puskuria, ja vältä liveness-probea, joka kilpailee samoista resursseista. Operatorin tarkistuksen pitää edelleen yrittää luoda bucket, ladata multipart-objekti, noutaa se presigned URL:n kautta ja varmistaa, että versionoidun poiston voi palauttaa aikataulutetusti.

Päivityksissä muista, että server-versiot, clientien allekirjoituskäyttäytyminen ja mahdollinen erasure-set-asettelu on testattava oikean bucket-metadatan kopiolla. Ota ehdokasversio käyttöön palautetun kopion päällä ja toista tunnettu testi. Jos clientit allekirjoittavat pyynnöt Consolen URL-osoitteelle S3 API -URL-osoitteen sijaan, etsi muuttunut oletus runtime-lokeista ja todellisesta verkkopyynnöstä.

Kerää näyttö ennen MinIO:n tuotantokäyttöä

Ennen oikeiden käyttäjien saapumista tee MinIO:lle release-työlista. Siinä on nimettävä pinnattu image, portti 9000, kanoninen origin, pysyvät polut ja palautettavista varmuuskopioista vastaava toinen levy tai etäkohde. Liitä mukaan tämän transaktion odotettu tulos: luo bucket, lataa multipart-objekti, nouda se presigned URL:n kautta ja varmista, että versionoidun poiston voi palauttaa.

Käytä työlistaa normaalin vaihdon ja puhtaan palautuksen jälkeen. Palautus hyväksytään vain, jos bucket-versiot, policyt, userit ja edustava multipart-objekti säilyvät palautuksessa eri tallennustilaan. Kerää lisäksi lyhyt resurssijälki, joka kattaa levyn latenssin, samanaikaiset multipart-lataukset, vapaan tilan puskurin ja sovellusten sekä S3-endpointin välisen verkkokapasiteetin; säilytä se releasen yhteydessä, jotta tulevia kapasiteettimuutoksia voidaan verrata samaan workloadiin.

Sisällytä yksi hallittu virhe: lähetä vaaratonta syötettä lähelle tähän rajaan liittyvää resurssi- tai formaattirajaa: clientit allekirjoittavat pyynnöt Consolen URL-osoitteelle S3 API -URL-osoitteen sijaan. Varmista, että MinIO raportoi ongelman oikealla rajalla, palauta kelvollinen tila ja suorita transaktio uudelleen. Tämä tarkistaa virheiden näkyvyyden, ei vain onnistumista, ja estää terveen näköistä käyttöliittymää peittämästä rikkinäistä workeria, callbackia tai tietokantayhteyttä.

Ota MinIO käyttöön Dockupissa rajoja rikkomatta

Dockup-templaten pitäisi määrittää image, portti 9000, mountit, health timing, domain, TLS ja secretien toimitus. Dockupin pitää säilyttää MinIO:n runtime-asetukset samalla, kun operaattori vahvistaa tämän paikallisen vaatimuksen: toinen levy tai etäkohde palautettavia varmuuskopioita varten. Sama deployment voi kohdistua Dockup-servereille tai asiakkaan liittämään kapasiteettiin.

Kun reitti on käytössä, ota public-asetus käyttöön ja kokeile bucketin luomista, multipart-objektin lataamista, objektin noutamista presigned URL:n kautta ja varmista, että versionoidun poiston voi palauttaa. Varmuuskopioi bucket-data, policyt, userit ja testatut objektitason replikat ja pidä palautusharjoitus osana operating plania; nämä ovat MinIO:n vastuulla ja pysyvät näkyvissä infrastruktuurin provisioinnin jälkeenkin.

Usein kysytyt kysymykset

Mitä MinIO tarvitsee tuotantokäyttöön?

Reititä MinIO-container portista 9000 yhden HTTPS-originin kautta. Paikallisen runtime-ympäristön vaatimus on toinen levy tai etäkohde palautettavia varmuuskopioita varten. Älä pidä MinIO:a valmiina, ennen kuin pystyt luomaan bucketin, lataamaan multipart-objektin, noutamaan sen presigned URL:n kautta ja varmistamaan, että versionoidun poiston voi palauttaa.

Mitkä MinIO:n tiedot kuuluvat varmuuskopioon?

Säilytä /data ja sisällytä bucket-data, policyt, userit ja testatut objektitason replikat samaan palautusmanifestiin. Puhdas MinIO-palautus onnistuu vain, kun bucket-versiot, policyt, userit ja edustava multipart-objekti säilyvät palautuksessa eri tallennustilaan.

Vaatiiko MinIO HTTPS:n reverse proxyn takana?

Käytä julkisessa MinIO-originissa HTTPS:ää ja pidä portti 9000 sisäisellä reitillä. Ota MinIO-asetus käyttöön oikein: reititä S3 API ja Console erillisiin hostnameihin, kun molemmat julkaistaan. MinIO:ssa HTTPS suojaa credentialit tai käyttäjäsisällön siirron aikana ja pitää origin-riippuvaisen client-käyttäytymisen yhdenmukaisena.

Miten MinIO-päivitys pitäisi testata?

Palauta nykyinen MinIO-tila eristettyyn deploymentiin, ota ehdokasversio käyttöön ja toista sen hyväksymistesti. Kiinnitä erityistä huomiota siihen, että server-versiot, clientien allekirjoituskäyttäytyminen ja mahdollinen erasure-set-asettelu on testattava oikean bucket-metadatan kopiolla. Säilytä edellinen MinIO-image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.