Nixpacks vs Dockerfile: Kumman buildin valitset?

Nixpacks vs Dockerfile -valinta määrittää, kuka omistaa build-määrityksen. Nixpacks johtaa build-suunnitelman tavanomaisesta repositoriosta, kun taas Dockerfile edellyttää repositorion tekijän määrittävän imagen rakentamisen vaihe vaiheelta. Dockup tukee molempia: repositorion Dockerfile on ensisijainen, ja Nixpacks toimii automaattisena varavaihtoehtona, jos Dockerfilea ei ole.

Kumpikaan vaihtoehto ei ole yleisesti ottaen ammattimaisempi. Oikea build on sellainen, jonka tiimisi pystyy toistamaan, debuggaamaan, suojaamaan ja ylläpitämään ilman tarpeetonta monimutkaisuutta.

Miten Nixpacksin automaattinen buildin tunnistus toimii?

Nixpacks tutkii repositorion tiedostoja päätelläkseen sovelluksen ekosysteemin, install-vaiheen, build-vaiheen, käynnistysvaiheen ja tarvittavat paketit. Tavallisia tunnisteita ovat paketimanifestit, lockfile-tiedostot, framework-konfiguraatiot ja tunnetut projektirakenteet.

Dockup-palvelussa automaattista tunnistusta käytetään, kun repositorio ei sisällä Dockerfilea. Ensimmäinen julkaisu voi siksi olla niinkin pieni kuin:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --deploy \
  --wait \
  --json

--dockerfile-valinnan puuttuminen ei ole virhe. Dockup kloonaa repositorion ja antaa Nixpacksin luoda build-suunnitelman.

Automaattinen buildin tunnistus toimii parhaiten, kun projekti noudattaa ekosysteemin käytäntöjä:

• Riippuvuudet on ilmoitettu vakiomuotoisessa manifestissa.
• Lockfile on commitoitu.
• Tavallinen build-scripti on nimetty vakiintuneen käytännön mukaan.
• Sovellus käynnistyy standardiscriptillä.
• Portti on määritettävissä runtime-ympäristön kautta.
• Native-riippuvuudet ovat providerin tunnistettavissa riittävän yleisiä.

Nixpacks vähentää pienen tiimin ylläpitämän infrastructure-koodin määrää. Framework-päivitys voi usein jäädä sovelluksen muutokseksi sen sijaan, että kontti pitäisi rakentaa uudelleen.

Virallinen Nixpacks-malli sisältää suunnitteluvaiheen ja build-vaiheen. Paikallista tutkimista varten Nixpacks CLI voi tulostaa tai suorittaa luodun suunnitelman. Dockupissa build-lokit ovat kuitenkin ensimmäinen paikka, josta kannattaa tarkistaa, mitä alusta valitsi.

Mitä hallintaa Docker-build tarjoaa?

Dockerfile ilmoittaa base-imagen ja kaikki merkittävät imagen rakentamisen vaiheet. Se sopii paremmin tilanteisiin, joissa runtime-ympäristöä ei voida ilmaista luotettavasti käytäntöjen avulla.

Tyypillisiä syitä ovat:

• Yksityinen tai erikoistunut base-image.
• Käyttöjärjestelmäpaketit, joita ei tunnisteta automaattisesti.
• Multi-stage-käännös.
• Useita sovelluksia samassa repositoriossa epätavallisilla kopiointirajoilla.
• Mukautettu non-root-runtime-käyttäjä.
• Selain-, media-, koneoppimis- tai native-kirjastoriippuvuudet.
• Tarkka entrypoint tai init-prosessi.
• Base-imagen alkuperää koskevat compliance-vaatimukset.

Minimalistinen Node.js-esimerkki on eksplisiittinen, mutta silti ylläpidettävä:

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
CMD ["node", "dist/server.js"]

Kun tämä tiedosto commitoidaan odotettuun sijaintiin, Dockup käyttää sitä Nixpacksin sijaan. Epästandardin polun voi antaa palvelua luotaessa dokumentoidulla --dockerfile-valinnalla.

Hallinta tuo mukanaan vastuun. Tiimi omistaa nyt base-imagen päivitykset, pakettien asennuksen, layer-cachen, kopioitavat tiedostot, käyttäjäoikeudet, entrypointin toiminnan ja arkkitehtuuriyhteensopivuuden.

Miten Nixpacks ja Dockerfile vertautuvat?

Käytännön erot on koottu alle:

Päätösalue	Nixpacks	Dockerfile
Alkuasetukset	Yleensä ei mitään	Imagen ohjeiden kirjoittaminen ja katselmointi
Buildin tunnistus	Automaattinen	Täysin eksplisiittinen
Yleiset frameworkit	Sopii hyvin	Toimii, mutta voi olla tarpeettoman raskas
Käyttöjärjestelmän mukautus	Rajoittuu tuettuun konfiguraatioon	Täysi hallinta
Base-image	Build-järjestelmän valitsema	Repositorion valitsema
Multi-stage-buildit	Luotu strategia	Tekijän määrittämä
Debuggauslähde	Luotu suunnitelma ja build-lokit	Dockerfile-rivi ja build-lokit
Ylläpito	Provider ja sovelluksen käytännöt	Sovellustiimi
Siirrettävyys	Riippuu Nixpacksin saatavuudesta	Standardi konttibuild
Tietoturvavastuu	Jaettu build-järjestelmän kanssa	Pääasiassa imagen tekijällä
Käynnistyskomennon omistajuus	Luodaan käytäntöjen perusteella	Imagen tekijän ilmoittama
Paras käyttökohde	Tavanomainen sovellus	Erikoistunut runtime

Nixpacks vs Dockerfile -päätös ei tarkoita “automaattinen vastaan toistettava”. Molemmat voivat olla toistettavia, kun riippuvuudet on lukittu ja ympäristö hallittu. Todellinen ero on “luotu suunnitelma vastaan repositorion omistama suunnitelma”.

Tavallisessa Node-, Python-, Go-, Ruby-, PHP- tai vastaavassa web-palvelussa aloita Nixpacksilla ja lisää Dockerfile vasta, kun sille ilmenee konkreettinen tarve. Erikoistuneelle native-kirjastoja käyttävälle workerille eksplisiittinen Dockerfile voi puolestaan olla pitkällä aikavälillä yksinkertaisempi valinta heti alusta lähtien.

Kumpi build on helpompi debugata ja toistaa?

Aloita alustan build-tulosteesta:

dockup logs production/api --build --json

Tai seuraa sitä reaaliajassa:

dockup logs production/api --build -f --json

Nixpacksia käytettäessä selvitä tunnistettu ekosysteemi, install-komento, build-komento ja käynnistyskomento. Virhe johtuu usein puuttuvasta lockfile-tiedostosta, odottamattomasta monorepon juuresta, käytännöstä poikkeavasta scriptinimestä tai native-paketista, joka tarvitsee käyttöjärjestelmätason riippuvuuden.

Dockerfilea käytettäessä selvitä epäonnistunut käsky ja sen build-konteksti. Tavallisia ongelmia ovat:

• .dockerignore sulkee pois tarvittavan tiedoston.
• Paketin asennus suoritetaan ennen tarvittavan manifestin kopiointia.
• Runtime-vaiheesta puuttuu käännetty artefakti.
• Kontti kuuntelee vain localhost-osoitteessa.
• Kontti käynnistyy käyttäjänä, jolla ei ole oikeutta lukea kopioituja tiedostoja.
• Base-image ei tue tarvittavaa arkkitehtuuria.
• Build-aikaiset salaisuudet päätyvät vahingossa layeriin.

Toistettavuus edellyttää muutakin kuin build-määrityksen. Lukitse sovelluksen riippuvuudet lockfile-tiedostoilla. Valitse base-imagen tagit harkiten. Vältä versioimattomien binäärien lataamista. Tee buildit riippumattomiksi tiedostoista, jotka ovat olemassa vain yhdellä kannettavalla.

Dockup voi ohittaa palvelun build- ja käynnistyskomennot:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Käytä overrideja pienen käytäntöpoikkeaman korjaamiseen. Jos projektiin kertyy paljon mukautettuja vaatimuksia, siirrä ne katselmoituun Dockerfileen tai selkeään repositoriokonfiguraatioon sen sijaan, että piilotat buildin dashboardin tilaan.

Miten tietoturva ja imagen ylläpito eroavat?

Kaikki build-polut tuottavat lopulta imagen, joka täytyy skannata ja pitää ajan tasalla. Dockup tarkistaa imagen tunnettujen CVE-haavoittuvuuksien varalta ja suorittaa konfiguraatiotarkistukset jokaisen julkaisun yhteydessä:

dockup security production/api --json
dockup security scan production/api --json

Nixpacks-käyttäjien tulee tarkistaa luotu runtime-valinta, päivittää sovelluksen riippuvuudet ja seurata tietoturvahavaintoja. Automaattinen ei tarkoita ylläpitovapaata.

Dockerfilea käyttävät omistavat lisäksi:

1. Base-imagen valinnan ja päivitystiheyden.
2. Ajamisen non-root-käyttäjänä aina kun se on käytännöllistä.
3. Salaisuuksien pitämisen poissa ARG-, ENV- ja kopioiduista tiedostoista.
4. Build-työkalujen erottamisen runtime-vaiheesta.
5. Pakettien versioiden lukitsemisen, kun vakaus sitä edellyttää.
6. Tarpeettomien käyttöjärjestelmäpakettien minimoimisen.
7. Health-tarkistusten ja signaalinkäsittelyn validoinnin.

Älä koskaan upota salaisuuksia ARG- tai ENV-määrityksiin, kopioituihin tiedostoihin tai build-lokeihin. Imagen määrityksen tulee olla turvallinen katselmoida ja rakentaa uudelleen ilman tuotantotunnusten upottamista siihen.

Security best practices -artikkeli käsittelee tuotannon laajempaa tietoturvakokonaisuutta. Build-valinta ei korvaa runtimen salaisuuksien hallintaa tai vähimpien oikeuksien periaatetta.

Milloin build-menetelmästä kannattaa vaihtaa toiseen?

Nixpacksista Dockerfileen vaihtaminen on perusteltua, kun toistuvien automaattisen buildin kiertoratkaisujen ymmärtäminen muuttuu vaikeammaksi kuin eksplisiittisen imagen ylläpito. Varoitusmerkkejä ovat:

• Useat dokumentoimattomat build-komennon override-määritykset.
• Native-paketit, jotka rikkoutuvat toistuvasti ympäristömuutosten jälkeen.
• Tarve standardoida sama image paikallisesti, CI:ssä ja useilla alustoilla.
• Tiukat base-image- tai käyttäjävaatimukset.
• Monoreporakenne, jonka automaattinen tunnistus tulkitsee jatkuvasti väärin.
• Suuret imaget, jotka vaativat harkittua multi-stage-optimointia.

Migraatio voidaan toteuttaa hallitusti:

1. Kirjaa onnistuneen Nixpacks-buildin build- ja käynnistystoiminta.
2. Kirjoita Dockerfile, joka toistaa sen paikallisesti.
3. Säilytä sama sovellusportti ja health-reitti.
4. Julkaise preview- tai ei-tuotantopalveluun.
5. Vertaa lokeja, käynnistysaikaa, imagen tietoturvahavaintoja ja smoke-testejä.
6. Committaa Dockerfile ja julkaise --wait-valinnalla.
7. Säilytä tunnettu aiemman julkaisun ID palautusta varten.

Myös Dockerfilesta takaisin Nixpacksiin siirtyminen voi olla järkevää. Legacy-konttimääritys saattaa sisältää vanhentuneita base-imageja, tarpeettomia paketteja tai kopioituja salaisuuksia. Poista se vasta, kun olet varmistanut, että Nixpacks tunnistaa oikean installin, buildin, käynnistyksen ja portin.

Käytä julkaisuhistoriaa palautukseen:

dockup deployments production/api -n 20 --json
dockup rollback <deploymentId> production/api --json

Git-repositorysta tuotantoon -opas kuvaa julkaisutyönkulun muun kokonaisuuden.

Työkuormakohtaiset suositukset

Työkuorma	Suositus aloittamiseen	Harkitse uudelleen, kun
Tavanomainen web-API	Nixpacks	Native- tai käyttöjärjestelmämukautukset lisääntyvät
Staattinen frontend, jota palvellaan sovellusprosessilla	Nixpacks	Mukautettu palvelin- tai image-politiikka vaaditaan
Käännetty Go-palvelu	Nixpacks tai Dockerfile	Tarkka scratch/distroless-runtime halutaan
Selainautomaatio	Dockerfile	Tarvittavat selainpaketit standardoidaan
Koneoppimisen inferenssi	Dockerfile	Runtime-imagea ja native-kirjastoja on hallittava
Monorepopalvelu	Nixpacks ensin	Tunnistus ei pysty eristämään oikeaa workspacea
Mukautettu base-image	Dockerfile	Base-image-politiikka tai runtime-vaatimukset muuttuvat
Pieni prototyyppi	Nixpacks	Prototyypistä tulee erikoistunut tuotantopalvelu

Kustannus- ja operatiiviset vaikutukset

Dockupin laskutus perustuu CPU-, RAM- ja levytilan kulutukseen minuutteina, ei siihen, käytettiinkö buildissa Nixpacksia vai Dockerfilea. Build-valinta voi silti vaikuttaa runtime-kustannuksiin epäsuorasti imagen koon, asennettujen prosessien, muistinkäytön ja käynnistyskäyttäytymisen kautta.

Tarpeettoman suuri image lisää siirto- ja tallennuskustannuksia. Build-työkaluja sisältävä runtime voi kasvattaa hyökkäyspinta-alaa. Toisaalta ylioptimoitu Dockerfile voi kuluttaa engineering-aikaa parantamatta varsinaista palvelua.

Tarkastele CPU-, RAM- ja levytilan kulutusta osoitteessa app.dockup.ai. Suositeltu Pro-plan maksaa 20 $ kuukaudessa ja sisältää 20 $ käyttöhyvitystä; maksulliset planit sallivat rajattomasti workspaceja, tietokantoja ja julkaisuja.

Lopullinen Nixpacks vs Dockerfile -sääntö

Valitse Nixpacks, kun repositorio on tavanomainen ja luotu suunnitelma on ymmärrettävä. Valitse Dockerfile, kun sovelluksella on vakaa vaatimus, joka on kuvattava eksplisiittisesti. Älä vaihda vain siksi, että toinen vaihtoehto kuulostaa hienostuneemmalta.

Luotettavin Nixpacks vs Dockerfile -lopputulos on build, jonka tiimisi pystyy luomaan uudelleen puhtaasta repositoriosta, selittämään häiriötilanteessa, pitämään paikattuna ja varmistamaan health-gated-julkaisulla.

Katso Dockup CLI -referenssistä ajantasaiset create-, build-asetus-, log- ja security-komennot. Zero-downtime-julkaisujen opas kertoo, miten kumpikin image etenee tuotantovalmiuden tarkistukseen.

Vertaa vikatilanteiden omistajuutta ennen valintaa

Build-järjestelmä on myös malli vikatilanteiden omistajuudelle. Nixpacksilla ensimmäinen kysymys on, valitsiko tunnistus oikean providerin ja vaiheet. Dockerfilella ensimmäinen kysymys on, ovatko repositorion ohjeet ja build-konteksti oikein.

Luo lyhyt eskalaatiokartta:

Virhe	Nixpacks-tutkinta	Dockerfile-tutkinta
Riippuvuuksien asennus	Manifesti, lockfile, tunnistettu paketinhallinta	COPY-järjestys ja asennuskäsky
Build-scripti puuttuu	Vakiintuneet scriptinimet tai override	RUN-komento ja työhakemisto
Native-kirjasto puuttuu	Tuetut paketit tai vaihto Dockerfileen	Base-jakelu ja paketinhallinta
Runtime-artefakti puuttuu	Luodut build- ja käynnistysvaiheet	Multi-stage-COPY --from-polku
Väärä portti	Palvelun portti ja sovelluksen sidonta	CMD, ympäristö ja sovelluksen sidonta
Käyttöoikeus evätty	Luotu runtime-käyttäjä/tiedostot	USER, omistajuus ja kopioitujen tiedostojen oikeudet
Base-image ei ole saatavilla	Tunnistettu runtime tai provider-valinta	Dockerfilen FROM-image ja tag
Suuri image	Luotu suunnitelma ja riippuvuudet	Layer-rakenne ja runtime-vaihe

Tämä taulukko auttaa agenttia välttämään väärän korjauksen. Dockerfilen lisääminen ei korjaa sovellusta, jolla ei ole kelvollista käynnistysscriptiä. Pakettiliscriptien uudelleenkirjoittaminen ei korjaa eksplisiittistä imagea, josta käännetty tuloste unohtui kopioida.

Arvioi paikallinen vastaavuus realistisesti

Dockerfile on houkutteleva, koska kehittäjät voivat ajaa samaa imagea paikallisesti, mutta vastaavuus ei synny automaattisesti. Tuotantoalusta tarjoaa imagen ulkopuolella edelleen ympäristömuuttujat, domainit, verkkoyhteydet, volumet, resurssirajoitukset ja health-tarkistukset.

Nixpacksia voi myös testata paikallisesti sen omilla työkaluilla, mutta tärkeä vastaavuuden kohde on toiminta: riippuvuuksien versiot, build-tulos, käynnistyskomento, kuunneltava portti ja tarvittavat runtime-tiedostot.

Kumman tahansa buildin kanssa:

1. Rakenna puhtaasta kloonista.
2. Poista testikoneelta ilmoittamattomat globaalit työkalut.
3. Käynnistä tuotannon kaltaisilla ympäristöavaimilla, mutta käytä tekaistuja arvoja.
4. Sido sama konttiportti.
5. Kutsu todellista readiness-reittiä.
6. Lopeta prosessi ja varmista signaalinkäsittely.
7. Rakenna uudelleen välimuistien poistamisen jälkeen.

Toistettava puhdas build on vahvempaa näyttöä kuin “toimii minun koneellani” riippumatta Nixpacks vs Dockerfile -valinnasta.

Huomioi monorepon rajat

Monorepot tuovat epäselvyyttä sovelluksen juuresta, riippuvuusgraafista ja artefaktien sijainnista. Automaattinen tunnistus saattaa löytää ylätason manifestin, vaikka palvelu sijaitsee useita hakemistoja alempana. Dockerfile saattaa vahingossa kopioida koko repositorion ja mitätöidä cachen jokaisella toisistaan riippumattomalla muutoksella.

Dokumentoi ennen valintaa:

• Palvelun juuri.
• Build-aikana tarvittavat jaetut paketit.
• Lockfile-tiedoston sijainti.
• Build-komento ja tuloshakemisto.
• Vain testaamiseen tarvittavat tiedostot.
• Runtimen työhakemisto.
• Docker-build-kontekstina käytettävä polku.

Jos pieni build-komennon override tekee tarkoitetusta workspacesta selkeän, Nixpacks voi edelleen olla sopiva. Jos build tarvitsee useita workspace-kohtaisia kopiointi- ja käännösvaiheita, Dockerfile voi ilmaista rajan rehellisemmin.

Älä ratkaise monorepon epäselvyyttä kopioimalla salaisuuksia tai paikallisia .env-tiedostoja build-kontekstiin. Runtimen salaisuudet kuuluvat Dockupin ympäristökonfiguraatioon.

Tarkista käynnistys- ja sammutuskäyttäytyminen

Onnistunut imagen build on vasta julkaisun keskivaihe. Kontin täytyy käynnistää oikea prosessi, kuunnella määritettyä porttia, pysyä etualalla ja sammua, kun alusta lähettää lopetussignaalin.

Tarkista nämä vikatilanteet:

• Shell-scripti käynnistää palvelimen taustalle ja päättyy.
• Development-server kuuntelee vain 127.0.0.1-osoitteessa.
• Prosessi jättää lopetussignaalin huomiotta ja viivästyttää korvaamista.
• Migraatiot suoritetaan jokaisella kontin uudelleenkäynnistyksellä ilman lukitusta.
• Käynnistyskomento käynnistää kehitykseen tarkoitetun watcherin.
• Dockerfile käyttää shell-muotoista CMD:tä, joka muuttaa signaalien välitystä.

Nixpacks luo käynnistysvaiheen framework-käytäntöjen perusteella, kun taas Dockerfile antaa tekijän valita CMD- tai ENTRYPOINT-määrityksen. Määritä kummassakin tapauksessa Dockup-palvelun portti ja mielekäs health gate:

dockup set production/api --port 3000 --json
dockup health production/api \
  --path /health \
  --interval 5 \
  --retries 5 \
  --json

Image on tuotantovalmis vasta, kun tämä runtime-käyttäytyminen on ennakoitavaa.

Luo build-muutoksille julkaisukäytäntö

Käsittele Nixpacksin ja Dockerfilen välistä vaihtoa infrastructure-muutoksena, vaikka sovelluskoodi ei muuttuisi. Vaadi katselmointi henkilöltä, joka tuntee runtimen, suorita preview-julkaisu ja vertaa tietoturvahavaintoja ennen tuotantoa.

Muutosmerkinnässä tulee ilmoittaa:

1. Aiempi build-menetelmä.
2. Vaihdon syy.
3. Base-image tai tunnistettu runtime.
4. Build- ja käynnistyskomennot.
5. Imagen tietoturvaluokitus ja vakavat havainnot.
6. Health-tarkistuksen tulos.
7. Runtimen smoke-testin tulos.
8. Aiemman julkaisun ID palautusta varten.

Tämä käytäntö estää “siivous”-Dockerfilea muuttamasta huomaamatta Node-, Python-, järjestelmäkirjasto- tai sertifikaattikäyttäytymistä. Se estää myös vanhan Dockerfilen poistamisen ennen kuin automaattinen suunnitelma on todistettu toimivaksi.

Nixpacks vs Dockerfile -valintaa voi arvioida uudelleen. Pidä päätös sidottuna nykyisiin vaatimuksiin, älä tiimin identiteettiin.

Pidä päätös näkyvänä

Kirjaa valittu build-menetelmä palvelun runbookiin ja pull request -malliin. Katselmoijien tulee tietää, korvaako uusi Dockerfile Nixpacksin tarkoituksella vai lisättiinkö se vahingossa. Yksi tällainen merkintä estää buildin omistajuuden hiljaiset muutokset.

Suosi näyttöä identiteetin sijaan

Tiimi ei ole “Dockerfile-tiimi” tai “Nixpacks-tiimi”. Arvioi build uudelleen, kun vaatimukset muuttuvat.

Aloita verifioitavasta julkaisusta

Julkaise yksinkertaisin edustava palvelu ensin Nixpacksilla ja ota Dockerfile käyttöön vasta, kun mitattu vaatimus tekee imagen eksplisiittisestä hallinnasta arvokasta.

Aloita ilmaiseksi osoitteessa app.dockup.ai. Free-plan maksaa 0 $ kuukaudessa, sisältää 10 $ aloitushyvitystä ja tukee yhtä workspacea, kolmea tietokantaa ja kolmea julkaisua.

Usein kysyttyä

Suosiiko Dockup Dockerfilea Nixpacksin sijaan?

Kyllä. Kun repositorio sisältää Dockerfilen, Dockup käyttää sitä. Kun Dockerfilea ei ole, Dockup käyttää Nixpacksin automaattista buildin tunnistusta.

Soveltuuko Nixpacks tuotantoon?

Kyllä, kun sovellus noudattaa tuettuja käytäntöjä, luodun buildin toiminta ymmärretään, riippuvuuksien versiot on lukittu ja tuotannon health- ja tietoturvatarkistukset läpäistään.

Milloin Dockerfile kannattaa kirjoittaa?

Käytä sitä, kun tarvitset eksplisiittisen base-imagen, käyttöjärjestelmäpaketteja, multi-stage-käännöksen, mukautetun runtime-käyttäjän, epätavallisen monorepokäyttäytymisen tai muuta tarkkaa imagen hallintaa.

Miten Dockup-buildia debugataan?

Lue viimeisimmät build-lokit komennolla dockup logs --build --json tai seuraa niitä komennoilla --build -f --json. Erota tunnistusongelmat Dockerfilen käskyjen virheistä.

Muuttaako build-menetelmä Dockupin hinnoittelua?

Ei. Nixpacksin ja Dockerfilen välillä ei ole suoraa plan-kohtaista veloituseroa. CPU-, RAM- ja levytilan kulutus mitataan minuutteina, vaikka imagen rakenne voikin vaikuttaa todelliseen resurssien käyttöön.