7 tilfælde, hvor du ikke skal bruge Docker

Docker er en game-changer. Men det er ikke en løsning, der passer til alle.

Der er mange gode ting ved Docker. Det pakker, sendes og kører applikationer som et let, bærbart og selvforsynende containeriseringsværktøj. Docker er fantastisk til virksomheder i alle størrelser. Når du arbejder på et stykke kode i et lille team, eliminerer det problemet "men det virker på min maskine". I mellemtiden kan virksomheder bruge Docker til at opbygge Agile-softwareleveringsrørledninger til at sende nye funktioner hurtigere og mere sikkert.

Med sit indbyggede containeriseringssystem er Docker et fremragende værktøj til cloud computing. Til gengæld fremmer Docker Swarm klyngerisering og decentraliseret design. Det lyder for godt til at være sandt, ikke? Der er stadig flere tilfælde, hvor Docker ikke skal bruges. Her er syv af dem.

Brug ikke docker

Lad os gennemgå disse en efter en.

Brug ikke Docker, hvis du har brug for at øge hastigheden

Docker-containere er mindre og kræver færre ressourcer end en virtuel maskine med en server og en database. Samtidig bruger Docker så meget systemressourcer, som værtsens kerneplanlægning tillader. Du bør ikke forvente, at Docker fremskynder en applikation på nogen måde.

Hvad mere er, Docker kan endda gøre det langsommere. Hvis du arbejder med det, skal du sætte grænser for, hvor meget hukommelse, CPU eller blok IO, containeren kan bruge. Ellers, hvis kernen registrerer, at værtsmaskinens hukommelse kører for lavt til at udføre vigtige systemfunktioner, kan den begynde at dræbe vigtige processer. Hvis den forkerte proces dræbes (inklusive selve Docker), vil systemet være ustabilt.

Desværre løser ikke Dockers hukommelsesjusteringer - prioriteten uden for hukommelsen på Docker-dæmonen - dette problem. Derimod kan et ekstra lag mellem en applikation og operativsystemet også resultere i hastighedsreduktion. Alligevel vil dette fald være ubetydeligt. Docker-containere er ikke fuldt isolerede og indeholder ikke et komplet operativsystem som enhver virtuel maskine.

Brug ikke Docker, hvis du prioriterer sikkerhed

Den største Docker-sikkerhedsfordel er, at den deler appen i mindre dele. Hvis sikkerheden for en del er kompromitteret, påvirkes ikke resten af ​​dem.

Imidlertid, mens isolerede processer i containere lover forbedret sikkerhed, deler alle containere adgang til et enkelt værtsoperativsystem. Du risikerer at køre Docker-containere med ufuldstændig isolering. Enhver ondsindet kode kan få adgang til din computers hukommelse.

Der er en populær praksis at køre mange containere i et enkelt miljø. Sådan gør du din app disponeret for angrebstypen Ressourcemisbrug, medmindre du begrænser ressourcebeholderfunktionerne. For at opnå maksimal effektivitet og isolering bør hver container henvende sig til et specifikt problemområde.

Et andet problem er Dockers standardkonfiguration - brugerne er ikke navneområde. Navneområder tillader, at softwareressourcer kun bruger andre ressourcer, hvis de hører til et bestemt navneområde.

At køre applikationer med Docker indebærer, at du kører Docker-dæmonen med rodrettigheder. Alle processer, der bryder ud af Docker-containeren, har de samme privilegier på værten som i containeren. At køre dine processer inde i containerne som en ikke-privilegeret bruger kan ikke garantere sikkerhed. Det afhænger af de muligheder, du tilføjer eller fjerner. For at mindske risikoen for Docker-containerudbrud skal du ikke downloade klar-til-brug-containere fra ikke-tillid til kilder.

Brug ikke Docker, hvis du udvikler et Desktop GUI-program

Docker passer ikke til applikationer, der kræver rig brugergrænseflade. Docker er hovedsageligt beregnet til isolerede containere med konsolbaserede applikationer. GUI-baserede applikationer er ikke en prioritet, deres support afhænger af den specifikke sag og applikation. Windows-containere er baseret på enten Nano eller Core Server - det tillader ikke brugere at starte en GUI-baseret grænseflade eller en Docker RDP-server i Docker-containeren.

Alligevel kan du stadig køre GUI-baserede applikationer udviklet med Python og QT-rammen i en Linux-container. Du kan også bruge X11-videresendelse, men denne løsning er noget akavet.

Brug ikke Docker, hvis du vil tænde for udvikling og fejlretning

Docker blev oprettet af udviklere og for udviklere. Det giver miljøstabilitet: en container på udviklingsmaskinen fungerer nøjagtigt den samme ved iscenesættelse, produktion eller ethvert andet miljø. Dette eliminerer problemet med forskellige programversioneringer i forskellige miljøer.

Med Dockers hjælp kan du nemt tilføje en ny afhængighed til din applikation. Ingen udviklere på dit team behøver at gentage denne manipulation på deres maskine. Alt vil være i gang i containeren og distribueres til hele teamet.

På samme tid skal du lave nogle ekstra opsætninger for at kode din app i Docker. Desuden er du med Docker-fejlretning nødt til at konfigurere logoutput og konfigurere fejlfindingsporte. Det kan også være nødvendigt at kortlægge porte til dine applikationer og tjenester i containere. Så hvis du har en kompliceret og kedelig implementeringsproces, hjælper Docker dig meget. Hvis du har en simpel app, tilføjer den bare unødvendig kompleksitet.

Brug ikke Docker, hvis du har brug for forskellige operativsystemer eller kerner

Med virtuelle maskiner kan hypervisoren abstrakte en hel enhed. Du kan bruge Microsoft Azure til at køre begge forekomster af Windows Server og Linux Server på samme tid. Docker-image kræver dog det samme operativsystem, som det blev oprettet til.

Der er en stor database med Docker-containerbilleder - Docker Hub. Alligevel, hvis et billede blev oprettet på Linux Ubuntu, kører det kun på nøjagtig samme Ubuntu.

Hvis en app er udviklet på Windows, men produktionen kører på Linux, kan du ikke bruge Docker effektivt. Nogle gange er det lettere at oprette en server, hvis du har flere statiske apps.

Brug ikke Docker, hvis du har en masse værdifulde data at gemme

Efter design oprettes alle Docker-filer inde i en container og gemmes på et skrivbart containerlag. Det kan være svært at hente dataene ud af containeren, hvis en anden proces har brug for det. Desuden er det skrivbare lag af en beholder forbundet til værtsmaskinen, som containeren kører på. Hvis du har brug for at flytte dataene et andet sted, kan du ikke gøre det let. Mere end det vil alle data, der er gemt inde i en container, gå tabt for evigt, når containeren lukkes ned.

Du skal først tænke på måder at gemme dine data et andet sted på. For at beskytte data i Docker skal du bruge et ekstra værktøj - Docker Data Volumes. Alligevel er denne løsning stadig ret klodset og skal forbedres.

Brug ikke Docker, hvis du leder efter den nemmeste teknologi til at styre

Introduceret i 2012 er Docker stadig en ny teknologi. Som udvikler skal du muligvis opdatere Docker-versioner regelmæssigt. Desværre er bagudkompatibilitet ikke garanteret. Desuden falder dokumentationen bag teknologiens fremskridt. Som udvikler skal du selv finde ud af nogle ting.

Derudover er de overvågningsmuligheder, som Docker tilbyder, ret dårlige. Du kan få et hurtigt indblik i nogle enkle statistikker. Alligevel, hvis du vil se nogle avancerede overvågningsfunktioner, har Docker intet at tilbyde.

I tilfælde af en stor og kompleks applikation koster implementeringen af ​​Docker også en pris. Opbygning og vedligeholdelse af kommunikation mellem mange containere på mange servere vil tage meget tid og kræfter. Alligevel er der et nyttigt værktøj, der gør det nemmere at arbejde med Docker-apps med flere containere - Docker Compose. Docker Compose definerer tjenester, netværk og diskenheder i en enkelt YAML-fil.

Ikke desto mindre er Docker-økosystemet ret brudt - ikke alle understøttende containerprodukter fungerer godt sammen. Hvert produkt bakkes op af et bestemt firma eller samfund. Den hårde konkurrence mellem disse resulterer i produktkompatibilitet.

At pakke op

KeenEthics-fagfolk nyder at arbejde med Docker og bruger det ofte til appudvikling. På trods af nogle ulemper kan du nemt bruge det til at køre og administrere apps side om side i isolerede containere.

Installation af en app kan være så simpelt som at køre en enkelt kommando -. Docker giver også et rent og originalt isolationsmiljø for hver test, hvilket gør det til et vigtigt og nyttigt værktøj til automatiseringstest.

Docker-funktioner giver fordele med hensyn til afhængighedsstyring og sikkerhed. Udvidet med sådanne nyttige værktøjer som Docker Hub, Docker Swarm og Docker Compose, er Docker en populær og brugervenlig løsning.

På trods af alle fordelene ved Docker, skal du ikke bruge den til at containerisere hver eneste applikation, du udvikler.

Husk: Docker er en game-changer. Men det er ikke en løsning, der passer til alle.

Docker er heller ikke det eneste værktøj på markedet. Alternativerne til Docker er rkt, udtalt som 'raket', Linux Containers eller OpenVZ. Hver af disse med sine fordele og ulemper ligner meget Docker. Den voksende popularitet og brugen af ​​Docker skyldes kun, at virksomheder beslutter at vedtage det.

Inden du springer til konklusioner, hvis du skal bruge Docker eller ej, skal du undersøge projektkravene. Tal med dine holdkammerater eller jævnaldrende, og lad dem hjælpe dig med at beslutte, hvornår du skal bruge Docker, hvornår du ikke skal bruge containere, og om det er en af ​​disse Docker-brugssager.

Uanset om du kan lide det eller ej, har denne teknologi en fremtid. Der er nogle udviklere og udviklingsagenturer, der hader Docker og forsøger at fjerne det fra alle deres igangværende projekter. Samtidig er der specialister, der containeriserer alt, hvad de kan, fordi de ser Docker som et universalmiddel. Måske skulle du ikke deltage i begge lejre. Bliv upartisk, bliv objektiv og tag en beslutning afhængigt af en bestemt situation.

Har du en idé til et Docker-projekt?

Mit firma KeenEthics er et team af erfarne webapplikationsudviklere. Hvis du har brug for et gratis skøn over et lignende projekt, er du velkommen til at kontakte .

Du kan læse flere af lignende artikler på min Keen Blog. Tillad mig at foreslå, at du læser Why to Refactor Your Code? eller softwareudviklingsmodeller forklaret: Outsourcing vs outstaffing, fast pris vs tid og materiale?

PS

Jeg vil også sige "tak" til Alex Pletnov for medforfatter til denne artikel såvel som læserne for at gøre det til slutningen!

Den originale artikel, der blev offentliggjort på KeenEthics-bloggen, kan findes her: 7 tilfælde, hvor Docker ikke skal bruges.