Docker, native of toch iets anders?

[HollowGamer]

Op dit moment heb ik 'maar' drie systemen:

VPS: productie
NUC: development/hosten lokale projecten
Desktop: development

Op de NUC en desktop gebruik ik Laradock en op productie (nog) niet.
Mijn plan was dan ook om Laradock ook daar uit te rollen, want dan hoef ik maar een simpele git pull te doen op de VPS en alle configuratie instellingen/wijzigingen zijn dan ook daar aanwezig.

Echter heb ik mij net wat meer ingelezen over Docker en het schijnt dat deze wat risico met zich meebrengt. Een 'native' oplossing zou het systeem beter beveiligen en ook op prestatie gebied kan er nogal veel verschil zijn. Klopt het dat Docker zich niks aantrekt van bijvoorbeeld SELinux of Apparmor?
Lokaal vind ik dat allemaal niet zo heel erg (zit achter firewall en niet bereikbaar vanaf WAN), maar op een VPS vind ik dat weer een ander verhaal.

Het is echter voor mij nogal een klus om wijzigen die ik doe lokaal ook meteen op productie te doen.
Niet dat dit heel veel voorkomt, maar met het uitrollen van projecten is dit natuurlijk er wel weer.

Ik vroeg mij dan ook af wat ik het beste zou kunnen doen. Docker, iets als ansible leren, of met scripts aan de gang?

Bedankt.

[ Voor 6% gewijzigd door HollowGamer op 01-08-2018 10:29 ]

[Verwijderd]

Wijzigingen tussen test/productie zou je moeten opvangen met bijvoorbeeld Ansible. Lees je in over Configuration Management (CM, en ook in CI/CD).

Het is aan te raden een SSOT te gebruiken. Mijn SSOT zit compleet in Ansible. Losse scriptjes om stuff te installeren zijn niet reproduceerbaar (behalve als ze gepush't worden met Ansible / iets soortgelijks).

Ik heb een main git-repo (met 219+ roles, ~12MB), en per klant een git-repo (enkele KB's).
^{B.v. in ~/ansible/main en ~/ansible/klantnaam}

Sowieso beheer je een server alleen via SSH. Configureer SSH keys om in te loggen. Die SSH-key kan je dan laden binnen een ssh-agent, waardoor Ansible die key kan gebruiken.

[ Voor 5% gewijzigd door Verwijderd op 01-08-2018 12:08 ]

[HollowGamer]

@Verwijderd Dat vind een goede manier, ga mij eens inlezen over het gebruik van Ansible.

Maak je wel gebruik van Docker of helemaal niet?

[Kettrick]

HollowGamer schreef op woensdag 1 augustus 2018 @ 12:26:
@Verwijderd Dat vind een goede manier, ga mij eens inlezen over het gebruik van Ansible.

Maak je wel gebruik van Docker of helemaal niet?

Ansible en Docker verschillen nogal van elkaar en lossen totaal verschillende problemen op.

Ansible is traditioneel een tool om servers to configureren, waarbij je verschillende rollen kan toepassen op servers. Dit wordt erg snel erg complex maar is een prima manier om servers te onderhouden.

Docker is een totaal andere manier van werken, er is in het geheel geen ondersteuning of taal waarin je werkt, een Dockerfile geeft je een kale server waar je wat bestanden in gooit en vervolgens wat commando's op uitvoert todat je een bepaalde staat bereikt. Zodra het werkt push/pull je de gehele server naar je echte server en daar start je het virtueel op.

Ik ben zelf een groot fan van docker, omdat projeten elkaar simpelweg niet in de weg kunnen zitten.

Docker bestaat overigens wel op een iets andere laag, en je zal alsnog andere tooling nodig hebben om je docker deployments te regelen.Hiervoor zou je mogelijk wel weer ansible kunnen gebruiken.

Een ansible config die docker installeert en vervolgens 10 containers start is simpel, een ansible config op 10 sites met alle quirks en plugins te installeren in 5 verschillende talen, drama

[Verwijderd]

Kettrick schreef op woensdag 1 augustus 2018 @ 12:38:
Ansible en Docker verschillen nogal van elkaar en lossen totaal verschillende problemen op.

Daarom gebruik ik Ansible als SSOT, waarmee ik Docker beheer. Dat werkt perfect, net als ik VMWare, KVM, LXC, etc beheer met Ansible.

Mijn VMWare ESXi role is redelijk uitgebreid zodat ik geen vCenter nodig heb. Ik mis dan alleen vMotion en soortgelijke mogelijkheden. W.d.b. 2 ESXi dozen, met daarop 2 VM's (1 per ESXi) om HA (active/passive of active/active) uit te rollen op server niveau (i.p.v. op virtualisatie niveau). Al veroorzaak ik geen conflicten met vCenter.

Ik ben zelf een groot fan van docker, omdat projeten elkaar simpelweg niet in de weg kunnen zitten.

Focker?

Eerst zal je fysieke servers/workstations (automatisch) moeten kunnen inrichten. Docker is het zoveelste laagje.

Docker bestaat overigens wel op een iets andere laag, en je zal alsnog andere tooling nodig hebben om je docker deployments te regelen.Hiervoor zou je mogelijk wel weer ansible kunnen gebruiken.

Vanuit Ansible's perspectief: Als het niet in de SSOT zit, kan ik geen Docker containers inrichten.
Ik kan vrij eenvoudig complete applicaties (verdeeld over tig servers/infra) virtualiseren op mijn PC.

Een ansible config op 10 sites met alle quirks en plugins te installeren in 5 verschillende talen, drama

Sites als locatie, of bedoel je websites? Ik heb geen probleem met 10 datacenter locaties. En ook niet met 10 websites. Alles automatisch met Ansible (incl switches, routers, etc. zijn allemaal computers...).

Per webapp heb ik een role, 20+ stuks. Waaronder WordCrap, euh, WordPress (met secured /wp-admin, etc), met plugins. Maar ook MediaWiki (incl plugins, zoals Semantic/SMW). De meeste webapps ondersteunen (al dan niet door DIY glue) SAML logins.

Ik weiger handmatige installaties/configuraties. En ik herinstalleer servers zonder overleg (binnen de maintenance window). Heeft een collega iets aangepast en niet in git staan (en dus in Ansible)? Dikke pech voor hem, alles kwijt.

[jj71]

HollowGamer schreef op woensdag 1 augustus 2018 @ 10:28:
Echter heb ik mij net wat meer ingelezen over Docker en het schijnt dat deze wat risico met zich meebrengt.

Ik weet even zo snel niet de details, maar het is wel zo dat Docker om bepaalde beveiligingen heen gaat als je het niet goed configureert.

Ik gebruik zelf Docker op mijn ontwikkelsysteem, waar Ubuntu op draait met firewall aan (ufw). Ik draai bijvoorbeeld MySQL in Docker. Bij het opstarten van de Docker container expose ik de nodige poorten, zodat ik vanaf mijn host OS bij de database kan die in Docker draait.

Als ik dat bij het "docker run" commando doe met bijvoorbeeld "-p 3306:3306" (dus poort 3306 in de container beschikbaar maken als poort 3306 op de host), dan kan de buitenwereld (andere computers in het netwerk) opeens zomaar bij de database die in mijn Docker container draait, ondanks dat ik de firewall aan heb staan!

Om dat tegen te gaan moet ik expliciet de port alleen maar voor localhost exposen door "-p 127.0.0.1:3306:3306" te doen. Als je het IP-adres er niet bij opgeeft, zet Docker het voor de hele wereld open en gaat dus zelfs om de firewall heen die in je host OS draait.

Dus er zijn inderdaad wel dingen waar je goed op moet letten in de configuratie van Docker.

[HollowGamer]

@jj71 Komt dit niet mede doordat Docker als root moet draaien?

Ik kies op dit moment voor deze oplossing:
- Docker voor development
- Native voor productie

Als het eenmaal is opgezet, hoe ik in de meeste gevallen enkel git pull te doen.
Daarna composer en/of npm en het zou goed moeten komen.

Ga eens kijken naar Ansible, want Docker lijkt me gewoon nog niet te veilig op productie of ga ik hierin te ver?

[ppl]

Kettrick schreef op woensdag 1 augustus 2018 @ 12:38:
Docker is een totaal andere manier van werken, er is in het geheel geen ondersteuning of taal waarin je werkt, een Dockerfile geeft je een kale server waar je wat bestanden in gooit en vervolgens wat commando's op uitvoert todat je een bepaalde staat bereikt. Zodra het werkt push/pull je de gehele server naar je echte server en daar start je het virtueel op.

Dat is niet wat Docker is en ook niet wat een Dockerfile is. Docker is een platform voor containerisatie en een Dockerfile is, heel simpel gezegd, een recept voor een container (iets beter gezegd: een Dockerfile zet je om naar een image en die image draai je als container).

Het grote voordeel van containerisatie is controle. Je hebt namelijk meer grip op de omgeving waarin je applicatie (of een deel daarvan) draait. Als je alles native installeert en je hebt 2 applicaties die dezelfde library gebruiken dan kom je soms in de problemen omdat de ene app een versie vereist waar de andere niet compatible mee is. Dan kun je ze dus niet naast elkaar op hetzelfde systeem draaien. Dat betekent ook dat je de server beheerders heel exact moet vertellen welke stukken software en welke versies er geïnstalleerd moeten worden op de server(s) waar de app op komt te draaien. Met een container hoeft dat niet. Het enige wat je daar dan nodig hebt is iets wat die container kan draaien. Alles wat nodig is zit al in die container dus het enige wat je nog hoeft te geven is de image van de container en hoe deze gedraaid moet worden (en zelfs dat kan weer in een cd/ci systeem).

Upgrades zijn ook makkelijker: je zet er gewoon een nieuwe container naast, test deze en als dat goed gaat zet je het live. Dat is ook de strategie voor een downgrade: ipv de nieuwe image pak je oude om als container te draaien. Probeer dat maar eens wanneer je allerlei packages geïnstalleerd hebt staan.

Dit maakt alles een stuk overzichtelijker en ook simpeler. Juist dat levert je dus meer grip op.

Overigens zie je in veel Docker security artikelen als tip om SELinux op de host die de containers draait aan te zetten. Overigens geldt voor Docker hetzelfde als voor vm's en fysieke servers: je ontkomt er niet aan om iets aan security te doen. En dat betekent ook dat je firewalls op de juiste plek in je netwerk moet zetten en je services niet op alle netwerkverbindingen moet laten luisteren. Overigens is de firewall van macOS afdoende, ik moet 'm hier uit zetten wanneer ik een container op mijn Mac vanuit het netwerk wil bereiken.

Dingen als Ansible en scripts kunnen je helpen om zo'n Docker image te maken en uiteindelijk ook als container ergens uit te rollen. Het zijn twee verschillende dingen die wel hand in hand samengaan.

@HollowGamer Docker is prima geschikt voor productie getuige het vele gebruik er van in productie systemen. En dan hebben we het ook niet alleen over de kleine jongens, Google maakt er ook veelvuldig gebruik van (zoveel zelfs dat ze daar met hun eigen orchestration tool kwamen: Kubernetes). Zelfs Microsoft gebruikt het op hun Azure platform (en leveren daar ook handige plugins voor bij hun open source code editor Visual Studio Code). VMware biedt het ook aan in hun enterprise producten (vSphere) en hebben zelfs een eigen Linux distro bedoeld om alleen containers te draaien (=Photon OS).

[idef1x]

HollowGamer schreef op zaterdag 4 augustus 2018 @ 20:51:
@jj71 Komt dit niet mede doordat Docker als root moet draaien?

Ik kies op dit moment voor deze oplossing:
- Docker voor development
- Native voor productie

Als het eenmaal is opgezet, hoe ik in de meeste gevallen enkel git pull te doen.
Daarna composer en/of npm en het zou goed moeten komen.

Ga eens kijken naar Ansible, want Docker lijkt me gewoon nog niet te veilig op productie of ga ik hierin te ver?

Je kunt ook LXD gebruiken ipv Docker...LXD (linux containers) hoeven niet onder root te draaien. Kun je die voor development en productie gebruiken

[Verwijderd]

HollowGamer schreef op zaterdag 4 augustus 2018 @ 20:51:
Ik kies op dit moment voor deze oplossing:
- Docker voor development
- Native voor productie

Ik zou beide omgevingen op het zelfde ding draaien. Of beide in Docker, of beide in virtualisatie (VMWare, KVM, LXC/LXD, etc). Anders zit je alsnog appels met peren te vergelijken als je software niet werkt, wegens 2 verschillende omgevingen. Dat is in mijn optiek geen legitieme test vs productie omgeving.

[Thralas]

idef1x schreef op zondag 5 augustus 2018 @ 08:14:
Je kunt ook LXD gebruiken ipv Docker...LXD (linux containers) hoeven niet onder root te draaien. Kun je die voor development en productie gebruiken

Zowel docker als lxd gebruiken onder water namespaces. Ook docker kun je containers laten starten als een andere gebruiker dan (namespaced) root.

Echter heb ik mij net wat meer ingelezen over Docker en het schijnt dat deze wat risico met zich meebrengt. Een 'native' oplossing zou het systeem beter beveiligen en ook op prestatie gebied kan er nogal veel verschil zijn.

Containers draaien allemaal onder één en dezelfde kernel (namelijk die van je container host).

Docker kun je gebruiken omdat het deployment sterk versimpelt, maar het feit dat het van binnenuit de container een gescheiden systeem lijkt is vooral praktisch. Als je zaken écht wilt scheiden dan draait het onder een andere kernel (lees: VM).

[Yarisken]

jj71 schreef op vrijdag 3 augustus 2018 @ 13:33:
[...]


Om dat tegen te gaan moet ik expliciet de port alleen maar voor localhost exposen door "-p 127.0.0.1:3306:3306" te doen. Als je het IP-adres er niet bij opgeeft, zet Docker het voor de hele wereld open en gaat dus zelfs om de firewall heen die in je host OS draait.

Dus er zijn inderdaad wel dingen waar je goed op moet letten in de configuratie van Docker.

Ik ben net met docker gestart en dit wist ik niet. Thx hiervoor, ga ik meenemen.

[ppl]

Dat is iets wat je altijd moet doen, of iets nou een Docker container draait of niet. Het heeft dus niets met Docker te maken.

Het enige verschil is de manier waarop je het doet. Bij een native geïnstalleerde service doe je dit in de config van de service zelf. Bij Docker doe je dit daar juist niet omdat je een container overal wil kunnen draaien, dus ook daar waar de ip-range anders is. Daarom zet je bij Docker de beperking op de container zelf.

Het kan wel anders wanneer je een Ansible playbook gebruikt. Daar kun je de image mee bouwen en met een meegegeven variabele het juiste ip-adres instellen. In datzelfde playbook zou je ook de gebouwde image weer als container kunnen laten uitrollen.

[ Voor 69% gewijzigd door ppl op 07-08-2018 21:06 ]

[CAPSLOCK2000]

Native is niet significant beter dan Docker, als je de boel goed inricht. Docker is niet meer dan een tool om wat extra binnenmuren te bouwen in je server. Het is een redelijk begin, maar het kan niet je enige vorm van beveiliging zijn.

In theorie ben ik groot fan van containers. In praktijk niet. Er zijn verschillende redenen, maar het komt eigenlijk allemaal neer op upgrades.

Het eerste probleem is dat heel veel mensen kant-en-klare docker-images gebruiken die ze van hun leverancier krijgen. Helaas zitten die typisch vol verouderde software omdat de leverancier alleen update als z'n eigen software dat nodig heeft. In plaats van twee keer per week een nieuw image te bouwen en daarin alle dependencies bijwerken. Het is minder hard nodig als je met goede base-images werkt, maar ik zie het vaker fout dan goed gaan.

Het tweede probleem is dat om een Docker te updaten je het hele image opnieuw moet bouwen, dan de oude container uitschakelen, de nieuwe starten, testen, en hopen dat alles goed is gegaan.
Als je zo groot bent als Google dan bouw je daar uiteraard een hele CI/CD omgeving voor die automatisch images bouwt, test en aan de loadbalancer toevoegd, of zo iets. Als je kleiner bent is het echter (te) veel infrastructuur om te behappen. Dus wordt er maar een slag naar geslagen. In mijn thuissituatie, om nog wat kleiner te gaan, duurt het bouwen van zo'n image al snel 10 minuten. Een beetje aanklooien om eens wat te testen zit er dan niet meer in.

Als laatste heb ik last van het 'turtles all the way down' effect. Hoeveel tools hebben we nu al niet om onze systemen te compartimentaliseren en te automatiseren? Toch blijven we steeds nieuwe abstractie lagen toevoegen om hetzelfde te doen. Je hebt nu al snel een hele stack: hardware -> os -> virtualisatie -> os -> docker -> os en iedere laag heeft z'n eigen tools die allemaal ongeveer hetzelfde doen. Een Docker-file of een Ansible-playbook hebben wel heel erg veel overeenkomsten. Het deployen van een stuk ijzer, een VM of een Docker is eigenlijk niet zo heel anders.
Het beheer van resources (geheugen, cpu, disk, netwerk) kun en moet je op al verschillende niveau's doen. Viritualisatie- en container-software heeft sowieso 90% overlap met wat het OS doet op procesniveau*. Processen schedulen, resources beheren, toegangscontrole, etc.. De overeenkomsten zijn groter dan de verschillen.

Er is gelukkig al een beetje een beweging de andere kant op. Tools als KVM en Docker proberen zo min mogelijk zelf te doen en zo veel mogelijk gebruik te maken van bestaande onderdelen van de Linux-kernel. Dat scheelt een hoop dubbel werk.

* je kan nog een stap dieper gaan. Applicaties denken nog steeds dat ze het enige stuk software op de hardware zijn en weten niet dat er ook nog een OS is. Het hele idee van een OS en losse processen is al een vorm van compartimentalisatie.

[vanaalten]

Ik heb mij nooit zo verdiept in Docker, min of meer om een reden die @CAPSLOCK2000 noemt: updates & stabiliteit.
Mijn prive-server draait al jarenlang op Debian 'stable'. Wat ik eigenlijk zou willen, wat mij over de streep zou kunnen trekken, is als Debian ook een repository met Docker containers gaat aanbieden. Dan weet je dat er voldoende naar securitypatches gekeken wordt en dat er updates komen indien nodig. Tot die tijd blijf ik er denk ik tegenaan hikken.

[DJMaze]

@CAPSLOCK2000 ik zie docker als de arbowet.
Vroeger boorde je een gat in de muur met een boor en een boormachine.
Van de Arbowet mag dat niet meer want dat is onveilig.
Je moet nu eerst werkschoenen met stalen neuzen, een brandveilige overal, werkhandschoenen, een veiligheidsbril en een helm op doen voordat je het gat mag boren.
Oh ja, de boormachine moet ook beveiligd zijn, zodat deze niet blijft ronddraaien als de boor ergens vast zit.

Als je 1000 gaatjes moet boren (Google) dan is het logisch, maar thuis 1 gaatje is overkill.

[ Voor 10% gewijzigd door DJMaze op 10-08-2018 03:22 ]

[ppl]

CAPSLOCK2000 schreef op donderdag 9 augustus 2018 @ 18:14:
Het eerste probleem is dat heel veel mensen kant-en-klare docker-images gebruiken die ze van hun leverancier krijgen. Helaas zitten die typisch vol verouderde software omdat de leverancier alleen update als z'n eigen software dat nodig heeft. In plaats van twee keer per week een nieuw image te bouwen en daarin alle dependencies bijwerken. Het is minder hard nodig als je met goede base-images werkt, maar ik zie het vaker fout dan goed gaan.

Dan adviseer ik je om eens naar Red Hat, SUSE, Debian, FreeBSD, OpenBSD, etc. te gaan kijken. Geen van allen hebben actuele software in hun standaard versies omwille van security. Wat ze wel hebben is oude software die door en door is getest en waar heel wat patches overheen zijn gegaan. Voor heel veel bedrijven is dit model juist de reden waarom ze die software gebruiken

Het is dus pertinent onjuist om te roepen dat verouderde software onveilig is. Dat is het alleen wanneer het niet goed wordt onderhouden. En laat dat nou ook opgaan voor hele actuele software. Het is namelijk niet de leeftijd dat iets veilig of onveilig maakt, maar de mate van onderhoud en het soort onderhoud wat men er aan pleegt. Dit geldt niet alleen voor containers maar voor alle soorten software. Dit zie je inderdaad vaak misgaan en daarbij maakt het dan ook geen drol uit of dit nou software is dat in een container of native draait.

Daarbij komt dat in veel gevallen men juist containers (en dat is niet per definitie Docker!) gebruikt om een bepaalde mate van scheiding aan te brengen. Dan worden containers juist gebruikt voor security omdat je er bijv. heel wat aan tools omheen kunt zetten om het veilig te houden. Bij FreeBSD is het zelfs dit zelfs de hoofdreden waarom ze daar überhaupt iets als containerisatie hebben (lees: jails).

Tot slot snijdt je hier ook een dilemma aan: ga je voor software waarvan de leverancier daar garantie en een SLA op levert qua werking of niet? In dat laatste geval betekent het in 99,99% van de gevallen dat je alleen de software geleverd krijgt en je het verder allemaal zelf mag uitzoeken (installatie, support, etc.).

Voor containers geldt hier exact hetzelfde als voor native software en in feite voor alle soorten software: haal ze bij een betrouwbare bron vandaan, zorg dat ze signed zijn (en check dat ook) en kijk wat ze doen alvorens je er gebruik van gaat maken. Dat betekent dat je dingen als nginx, jenkins, etc. gewoon bij de makers van de software moet halen. Wil je er meer dingen bij hebben, bouw dan je eigen image en doe dat op basis van een image met goede reputatie. Zet dan ook security scan tools in zoals CoreOS Clair zodat je tijdens het bouwen of bij het pushen naar je registry kunt checken of de security op orde is (en met de juiste tooling kun je ook meteen voorkomen dat onveilige images worden gepusht/pullt of zelfs gebouwd).

Het tweede probleem is dat om een Docker te updaten je het hele image opnieuw moet bouwen, dan de oude container uitschakelen, de nieuwe starten, testen, en hopen dat alles goed is gegaan.

En zie daar het probleem: "hopen dat alles goed is gegaan". Dat is exact hoe heel veel upgrades gaan en ook hier maakt het weer totaal niet uit of dit nou software in een container is of native. Bij upgrades zie je dat er vaak weinig wordt getest, er geen plan b is en al helemaal geen rollback optie wordt bedacht. Docker of native lost dit probleem niet voor je op, daar zul je toch echt zelf wat voor moeten gaan bedenken. Containers kunnen je hier wel bij helpen omdat je vrij snel even een container aan kunt slingeren en er wat tests tegenaan kunt gooien. Dat gaat wat makkelijker dan wanneer je een complete omgeving moet gaan optuigen.

Als je zo groot bent als Google dan bouw je daar uiteraard een hele CI/CD omgeving voor die automatisch images bouwt, test en aan de loadbalancer toevoegd, of zo iets. Als je kleiner bent is het echter (te) veel infrastructuur om te behappen.

Dit is gewoon een gevalletje overdrijven tot kunst verheffen. Zo spannend is zo'n CI/CD omgeving niet en zo'n loadbalancer ook niet. Er zijn legio tutorials hierover te vinden waar je vrij snel doorheen loopt.

Dus wordt er maar een slag naar geslagen. In mijn thuissituatie, om nog wat kleiner te gaan, duurt het bouwen van zo'n image al snel 10 minuten. Een beetje aanklooien om eens wat te testen zit er dan niet meer in.

Dat is nietszeggend. Het is maar net wat je bouwt en hoe je het bouwt. Waar men echter veelal op aandringt is het zo klein en zo plat mogelijk houden van je images. Dat zorgt er niet alleen voor dat ze snel worden gebouwd maar ook dat je ze snel kunt uitrollen. Security checks zoals middels CoreOS Clair zijn dan ook sneller klaar. Ook dit levert een bijdrage aan een veiligere container.

Het beheer van resources (geheugen, cpu, disk, netwerk) kun en moet je op al verschillende niveau's doen. Viritualisatie- en container-software heeft sowieso 90% overlap met wat het OS doet op procesniveau*. Processen schedulen, resources beheren, toegangscontrole, etc.. De overeenkomsten zijn groter dan de verschillen.

Laat dat nou net allemaal zaken zijn waar het nou juist helemaal niet om gaat. De computing power is nu op een dusdanig niveau dat we niet kieskeurig hoeven te zijn. Die extra beetjes overhead van zaken als virtualisatie en containerisatie valleen in het niet bij het gemak wat je op beheer en develop gebied terugkrijgt. Dat wil niet zeggen dat men helemaal niets meer optimaliseert, dat gebeurd nog steeds.

* je kan nog een stap dieper gaan. Applicaties denken nog steeds dat ze het enige stuk software op de hardware zijn en weten niet dat er ook nog een OS is. Het hele idee van een OS en losse processen is al een vorm van compartimentalisatie.

Of nog dieper met iets als Amazon Lambda waar je alleen maar een script draait. Amazon regelt de rest voor je.

Dat laatste is bij Amazon, Microsoft, Google, IBM, enz. nou juist het idee: jij doet een bepaald deel, zij doen de rest.

TL;DR: wat je hier roept heeft niets met Docker te maken omdat het voor alle soorten software opgaat.

[HollowGamer]

vanaalten schreef op donderdag 9 augustus 2018 @ 19:20:
[..]
Wat ik eigenlijk zou willen, wat mij over de streep zou kunnen trekken, is als Debian ook een repository met Docker containers gaat aanbieden. Dan weet je dat er voldoende naar securitypatches gekeken wordt en dat er updates komen indien nodig. Tot die tijd blijf ik er denk ik tegenaan hikken.

Wat is de meerwaarde als Debian dit aanbiedt i.p.v. een actieve community?
Je gebruikt Debian als OS en daarop draai je de containers, waar die ook vandaan komen maakt dan toch niet veel uit? Waarom zou Debian hier wel rekening mee houden en andere niet?

[vanaalten]

HollowGamer schreef op zaterdag 11 augustus 2018 @ 10:30:
[...]

Wat is de meerwaarde als Debian dit aanbiedt i.p.v. een actieve community?
Je gebruikt Debian als OS en daarop draai je de containers, waar die ook vandaan komen maakt dan toch niet veel uit? Waarom zou Debian hier wel rekening mee houden en andere niet?

Debian heeft wel een reputatie en richt zich op betrouwbaarheid & veiligheid. Een community richt zich eerder op features en up-to-date zijn. En zal, verwacht ik, beperkter zijn in welke software/containers ze aanbieden. Ik wil dan ook niet wekelijks meerdere container-updates ontvangen, enkel updates als er security-updates nodig zijn.

Maar ik ben daar niet heel strikt in. Als er een actieve community is die een soort van long-term-maintenance aanpak hanteert voor een redelijk aanbod aan containers, dan kan ik dat ook al interessant gaan vinden.

[ppl]

Die container updates heb je zelf in de hand. Er zit geen automatische update functie in by default, dat kun je wel middels bepaalde tools inrichten. Om op de hoogte van security issues te blijven zul je, net als altijd, je moeten inschrijven op dat soort lijsten. Daarna kun je, net als altijd, zelf beslissen wat je gaat doen.

Als je een image gebruikt dan kun je er voor kiezen om niet de tag "latest" te gebruiken maar juist een specifieke versie. Net als met andere vormen van software wil een softwaremaker ook wel een LTS versie van z'n app aanbieden, die kun je natuurlijk ook gebruiken.

Onderstaand filmpje geeft een goede inzage in waar je moet opletten wanneer je een Docker image maakt. De security scan van zo'n image komt hier ook aan bod. Het is een lange zit maar zeker de moeite waard.

[vanaalten]

ppl schreef op zaterdag 11 augustus 2018 @ 15:30:
Die container updates heb je zelf in de hand. Er zit geen automatische update functie in by default, dat kun je wel middels bepaalde tools inrichten. Om op de hoogte van security issues te blijven zul je, net als altijd, je moeten inschrijven op dat soort lijsten. Daarna kun je, net als altijd, zelf beslissen wat je gaat doen.

Ja, maar ik wil het veel makkelijker hebben dan dit.
Nu: Debian installatie en diverse applicaties zoals Apache, MySQL, Postfix haal ik uit hun repository. En zij doen het onderhoud voor mij: houden in de gaten of er security issues zijn en lossen die op. En automatisch wordt het spul op m'n systeem bijgewerkt.

En zo wil ik het ook met die containers zien: ik installeer alle container-tools vanaf 1 repository (Debian, of een ander die ik vertrouw) en als er een lek in Apache gedicht wordt, krijg ik automagisch een security-fixed container-update.

Geen functionele updates tot ik zelf besluit naar een volgende versie van Debian te gaan. Geen mailinglijsten, want niet nodig.

* vanaalten gaat op vakantie en reageert even een weekje niet meer.

[ppl]

En dat kan dus ook prima met die containers. Je moet er wellicht iets meer voor doen maar het is niet onmogelijk. Kijk eens naar Watchtower.

[HollowGamer]

vanaalten schreef op zaterdag 11 augustus 2018 @ 15:03:
[...]

Debian heeft wel een reputatie en richt zich op betrouwbaarheid & veiligheid. Een community richt zich eerder op features en up-to-date zijn. En zal, verwacht ik, beperkter zijn in welke software/containers ze aanbieden. Ik wil dan ook niet wekelijks meerdere container-updates ontvangen, enkel updates als er security-updates nodig zijn.

Ik denk dat je dan eerder naar de *BSD kant moet gaan. Debian richt zich inderdaad meer op stable, maar dat zegt nog niet altijd iets over veiligheid. Ze rusten gewoon meer op LTS.

Security updates kun je nog altijd zelf bepalen of zelf iets opzetten (al ben ik nog niet zover hierin) op basis van Debian. Maar zoals @jj71 moet je wel weten wat je doet.

[ppl]

De enige BSD die iets met containers doet is FreeBSD en die bieden dat niet. De enige optie die je hebt is het FreeBSD package management in een jail gebruiken (alle andere opties gebruiken een niet-FreeBSD iets). Zoiets kun je ook doen met Debian en Docker; hebben ze zelfs een handleiding voor. Makkelijk is het niet maar je kunt dan wel gebruik maken van alle software in de door Debian onderhouden repo's en Debian's standaard package manager.

[Verwijderd]

Lokaal vind ik dat allemaal niet zo heel erg (zit achter firewall en niet bereikbaar vanaf WAN), maar op een VPS vind ik dat weer een ander verhaal.

Dan richt je een VPS als firewall in wat sowieso verstandig in een public cloud omgeving. Jouw provider zal de grootste vliegen voor je afvangen maar je bent voor de rest zelf verantwoordelijk. En een host firewall alleen is onvoldoende. Zaken wat Ansible of containerisation niet kan fixen.

[Verwijderd]

Verwijderd schreef op zondag 12 augustus 2018 @ 15:17:
Zaken wat Ansible of containerisation niet kan fixen.

Wat kan Ansible dan niet fixen?

Ik richt er complete datacenters mee in. Een klein firewalletje is het probleem niet. Ook Docker en andere containers zijn geen probleem voor Ansible. De meest beperkende factor is de gebruiker (layer8) i.m.h.o.

[ Voor 10% gewijzigd door Verwijderd op 12-08-2018 17:12 ]

[ppl]

Ansible en containerisation zijn geen firewall, het is resp. tooling voor configuration management en een vakterm. Die gaan je dus niet helpen met security waar een firewall dat wel doet: het blokkeren of toestaan van verkeer van/naar de service die in de container(s) draait.

Nogmaals, Docker is niet meer dan een tool om je applicatie te verpakken en te verschepen. Ansible is een stukje tooling die je kunt gebruiken om die verpakking te maken en het pakketje ergens neer te zetten. Beveiliging e.d. zul je zelf moeten regelen. Dat betekent afdoende firewall van host, netwerk, etc. maar ook het up to date houden van de images zelf en natuurlijk ook secure coding van je applicatie zelf. Dit is layer 8 en daar doen Docker en Ansible dus echt helemaal niks mee

[ Voor 93% gewijzigd door ppl op 12-08-2018 22:47 ]

[Verwijderd]

ppl schreef op zondag 12 augustus 2018 @ 22:42:
Ansible en containerisation zijn geen firewall, het is resp. tooling voor configuration management en een vakterm. Die gaan je dus niet helpen met security waar een firewall dat wel doet.

Denk je dat men high-available routers / firewalls met de hand beheerd?

Met Ansible beheer ik tig grote firewalls, switches, etc. De complete firewall configuratie staat in Ansible (met git). Zodra ik een playbook start checkt het o.a. alle firewall regels, interfaces, etc.

Er is o.a. https://docs.ansible.com/...t_of_network_modules.html met grote vendors als Juniper, F5, etc. Maar ook de custom / kleinere firewalls zijn perfect te beheren (Ansible bied er genoeg modules voor, bouw je eigen roles voor "custom hardware").

Hoe helpt dat niet bij security?

Ansible is een stukje tooling die je kunt gebruiken om die verpakking te maken en het pakketje ergens neer te zetten.

Heb je uberhaupt ooit gekeken naar Ansible? Verpakking? Pakketje ergens neer te zetten? Waar heb je het over?

[Kettrick]

ppl schreef op zondag 12 augustus 2018 @ 22:42:
Dit is layer 8 en daar doen Docker en Ansible dus echt helemaal niks mee

Niet helemaal waar, als je traditioneel een VM inricht en vervolgens dagelijks je code braaf upload maar te lui bent om the software to updaten kom je er vroeg of laat achter dat je enorm achter loopt met je updates.

Als je docker in combinatie met een standaard base image gebruikt (java:8, php:7, python:3, etc) werk je vrijwel altijd op de laatste versies. Uiteraard kan je ook zelf periodiek images bouwen als je dat liever doet,het idee blijft hetzelfde.

Als je alles op docker hebt draaien is je host platform opeens een stuk minder interresant, als onze deployments gaan automatisch middels terraform ( wat ik overigens vele male beter vind werken dan ansible, maar dat is een andere discussie ). Zodra amazon een nieuwe ECS AMI beschikbaar maakt wordt dat door terraform automatisch aangepast tijdens de volgende release ( lees commit ).

Docker, of een andere container tech, kan wel degelijk bijdragen aan het up to date houden van software.

[ppl]

Verwijderd schreef op maandag 13 augustus 2018 @ 03:12:
Denk je dat men high-available routers / firewalls met de hand beheerd?

Is het nou werkelijk zo moeilijk om te begrijpen dat het hier om de appliance zelf gaat en niet om het beheer van de appliance?

Het is heel simpel: beheertooling in welke soort of vorm dan ook kan geen pakketjes filteren of tegenhouden. Een firewall zoals pfSense, van Cisco, Palo Alto en ga zo maar door kunnen dat wel.

Leuk dat je ansible als beheertool gebruikt maar dat heeft alleen zin als je iets hebt om te beheren zoals eerder genoemde firewall die het eigenlijke werk van filtering en blocking doet.

Leer het onderscheid tussen beheertool en tool die je daarmee beheert!

Hoe helpt dat niet bij security?

Wat je hier nu roept is dat mensen alleen maar een boek over security hoeven te kopen en dat daarmee hun hele omgeving hartstikke secure is. Je boek gaat net als Ansible geen verkeer tegenhouden. Een firewall van Cisco wel.

Heb je uberhaupt ooit gekeken naar Ansible? Verpakking? Pakketje ergens neer te zetten? Waar heb je het over?

Als je niet weet waar ik het over hebt lijkt het me verstandig om je eens in te gaan lezen over wat ansible en docker voor tools zijn en vooral wat je kunt doen als je deze combineert. Een goede start voor dat laatste zijn de docker modules van ansible (met name docker_container en docker_image). Daarnaast zijn er ook tig artikelen en blogposts (o.a. van docker en ansible mensen zelf) waarin dit soort zaken worden uitgelegd. In menig Linux blaadje zul je het ook terug vinden. Tot slot zijn er ook nog zat ervaringen te lezen van mensen die docker-compose hebben ingeruild voor ansible. Ansible is niet de enige beheertooling die dat kan. Zie ook de reactie van Kettrick.

Kettrick schreef op maandag 13 augustus 2018 @ 07:37:
Niet helemaal waar, als je traditioneel een VM inricht en vervolgens dagelijks je code braaf upload maar te lui bent om the software to updaten kom je er vroeg of laat achter dat je enorm achter loopt met je updates.

Yep en degene die daar verantwoordelijk voor is en dat allemaal inricht is dus layer 8 M.a.w. dat is de gebruiker aka iedereen die de software gebruikt dus ook de ontwikkelaar, de netwerkbeheerder of de systeembeheerder.

Als je alles op docker hebt draaien is je host platform opeens een stuk minder interresant, als onze deployments gaan automatisch middels terraform ( wat ik overigens vele male beter vind werken dan ansible, maar dat is een andere discussie ). Zodra amazon een nieuwe ECS AMI beschikbaar maakt wordt dat door terraform automatisch aangepast tijdens de volgende release ( lees commit ).

Ansible en Terraform gebruik je voor verschillende dingen. Terraform is vooral leuk voor de infra zoals networking, firewalling, servers en dat soort zaken. Ansible is dan weer leuk voor wat er op die servers komt te draaien. Zou je het beide met 1 van de 2 kunnen? Vast wel, ligt er maar net aan wat je precies zoekt/nodig hebt. Anno nu is het echter wel aan te raden om naar dit soort tooling te kijken. Het kost je in het begin veel tijd maar eenmaal opgezet geeft het je wel de mogelijkheid om heel snel dingen zonder grote gevolgen te upgraden of nieuwe omgevingen op te zetten. Daar zit de echte winst.

Docker, of een andere container tech, kan wel degelijk bijdragen aan het up to date houden van software.

Het is alleen geheel aan de layer 8 om dat in te richten.

Een schroevendraaier en een hamer ontwerpen en bouwen je huis niet. Het zijn architecten en bouwvakkers die zo'n huis bouwen. M.a.w. Docker, Ansible, Terraform en noem maar op zijn niet meer dan tools zoals die schroevendraaier en hamer. Het is aan jou als gebruiker (of je nou beheerder, ontwikkelaar of wat dan ook bent, je gebruikt de tools en dus ben je gebruiker) om te bepalen hoe je infrastructuur en applicatie eruit ziet en welke tools je daarvoor moet gaan gebruiken.

[Verwijderd]

ppl schreef op dinsdag 14 augustus 2018 @ 21:45:
Leer het onderscheid tussen beheertool en tool die je daarmee beheert!

Daar heb ik echt geen probleem mee.

Wat was eerder? De kip of het ei?

Je boek gaat net als Ansible geen verkeer tegenhouden. Een firewall van Cisco wel.

De firewall van Cisco is de tool die het uitvoert, nadat het is geconfigureerd door Ansible. Die Cisco firewall is gewoon een host in mijn inventory.

Als je niet weet waar ik het over hebt lijkt het me verstandig om je eens in te gaan lezen over wat ansible en docker voor tools zijn en vooral wat je kunt doen als je deze combineert.

Je klinkt een beetje als een betweter. Ik gebruik Ansible al sinds 2012, early adopter.

Zou je het beide met 1 van de 2 kunnen? Vast wel, ligt er maar net aan wat je precies zoekt/nodig hebt.

Kijk, dat is een interessante vraag. Ik denk dat het uiteindelijk het zelfde resultaat kan hebben, afhankelijk van wat je wil. Ik heb geen ervaring met TerraForm, paar video's gekeken, werkt functioneel wat anders dan Ansible. Allicht dat ik TerraForm een stuk intelligenter kan noemen.

Juist omdat Ansible meer straight forward is, ben ik b.v. van Puppet (en dergelijke) afgestapt. Ansible staat me toe om zelf een execution-path te realiseren (en delen via git). Playbook met wat includes, b.v. eerst de hypervisor's (van BCM/iLo/whatever config, PXE install tot het aanmaaken van de juiste VM's) en daarna de vm's beheren. Dat execution path is eenvoudig te bedenken. En ik heb garantie dat het de door mij ingestelde volgorde verloopt. Dat het een check (dry run in puppet) doet, of delen uitvoert die ik specifiek wil.

Ik heb niet vaak iets met externe clouds te maken, meer met private/onsite DC's (meer upscalen van power, dan downscalen/virtualiseren). Behalve b.v. wat externe VM's (MX/DNS/PBX) op meerdere onafhankelijke clouds (vaak zonder API naar de betreffende clouds, toch vaak beperkt tot 3~4 VM' totaal van dat soort).
Vaak kom ik wel een paar interne virtualisatie omgevingen tegen (leuk voor wat simpele services), maar vooral veel dedicated spul, powerusers met dikke servers en/of dikke workstations, die o.a. R programmeren.

Docker is dan zo'n ding wat in sommige zakelijke projecten voorkomt. Sure, whatever gets the job done.

De admin cloned een git repo en kan zelf infra uitrollen (nadat zijn SSH-keys zijn uitgerolt, of autom. via PXE setup, of manual met een bootstrap.sh). Lokaal een project testen, zoals een paar VM's, of een nieuwe firewall die nog op bureau ligt voor initial setup (mgmt IP/interface, etc) guided by Ansible.
^{Een config repo per omgeving/bedrijfsonderdeel/whatever isolation. Met een main repo die de meeste logica bevat.}

Ochja, infra discussie. Meerdere wegen naar rome! IaC (Infra as Code) is in mijn inziens vooral afhankelijk van dat het in git zit (al dan niet via Phabricator of GitLab). En je geen handwerk hebt (het is tenslotte automatisering).

[ppl]

Verwijderd schreef op woensdag 15 augustus 2018 @ 02:19:
Daar heb ik echt geen probleem mee.

Wat was eerder? De kip of het ei?

Als dat zo was dan had je die 1e reply al niet gedaan en zeer zeker niet deze kip of het ei vraag gesteld. Beheertooling als Ansible gebruik je om ergens centraal je settings vast te leggen, dat in versiebeheer te houden zodat je exact weet wie, wat, wanneer iets heeft gewijzigd en vooral ook waarom. Dat heb je echter niet nodig om een firewall in te richten. M.a.w. er is hier geenszins sprake van een kip-ei situatie.

De firewall van Cisco is de tool die het uitvoert, nadat het is geconfigureerd door Ansible.

Precies. Als je het dan hebt over het uitvoerende deel, heeft het beherende deel er niets mee te maken. In dit geval ging het om een aparte server die als firewall dient en voor de host die de docker containers draait staat maar bovenal om het feit dat security meer is en je het vooral allemaal zelf moet bedenken. Het hele ontwerp gedeelte is en blijft het lastigste.

Je klinkt een beetje als een betweter. Ik gebruik Ansible al sinds 2012, early adopter.

Sja, je vroeg er om omdat je zelf als betweter gedroeg Overigens gebruiken bij ons de service managers ook Ansible...wil nog niet zeggen dat ze er ook inhoudelijk verstand van hebben (m.a.w. dat zegt wel wat voor dingen je met Ansible voor elkaar kunt krijgen: iets wat zo makkelijk is te draaien dat je er geen inhoudelijke kennis van hoeft te hebben). Buiten dat is Ansible 1 van de vele beheertools. Er zijn er zat die hun oude vertrouwde scripts (shell, perl, python, you name it) gebruiken. Het gaat dan ook niet om de exacte tool maar het principe erachter.

Juist omdat Ansible meer straight forward is, ben ik b.v. van Puppet (en dergelijke) afgestapt. Ansible staat me toe om zelf een execution-path te realiseren (en delen via git). Playbook met wat includes, b.v. eerst de hypervisor's (van BCM/iLo/whatever config, PXE install tot het aanmaaken van de juiste VM's) en daarna de vm's beheren. Dat execution path is eenvoudig te bedenken. En ik heb garantie dat het de door mij ingestelde volgorde verloopt. Dat het een check (dry run in puppet) doet, of delen uitvoert die ik specifiek wil.

Dat is het voordeel van de oude scripts en tooling als Ansible. Je kunt exact (of vrij exact) aangeven wat er moet gebeuren.

Dat is ook meteen het nadeel want je moet ook exact weten hoe dingen doorlopen moeten worden. Andere tools spelen daar juist weer op in doordat je alleen maar de eindstand definieert. De tool zoekt dan zelf uit hoe die eindstand gemaakt moet worden. Terraform is iets wat vooral in deze laatste categorie valt. Zo kun je opgeven wat je in bijv. AWS of Azure wilt zien en terraform gaat zelf uitzoeken wat hij wanneer moet doen en met welk commando dat moet gebeuren.

Ochja, infra discussie. Meerdere wegen naar rome! IaC (Infra as Code) is in mijn inziens vooral afhankelijk van dat het in git zit (al dan niet via Phabricator of GitLab). En je geen handwerk hebt (het is tenslotte automatisering).

Precies en daarom is het handig dat je een beetje ervaring opdoet met tools als Docker en Ansible, en dan ook vooral hoe je ze kunt combineren. En daar hoef je niet eens zoveel fancy dingen voor te doen.

Wat ik je hier niet zie noemen is dat dit soort tooling ook fouten kan voorkomen en zaken uniform houdt. Je krijgt doordat je alles in templates kunt gieten vrijwel geen wildgroei meer. Door gebruik van dit soort tools icm dingen als Jenkins kun je er ook nog eens voor zorgen dat mensen die geen kennis van zaken hebben ook gewoon een omgeving kunnen upgraden. Hoef je dat zelf niet meer te doen

[Verwijderd]

Verwijderd schreef op zondag 12 augustus 2018 @ 17:11:
[...]

Wat kan Ansible dan niet fixen?

Ik richt er complete datacenters mee in. Een klein firewalletje is het probleem niet. Ook Docker en andere containers zijn geen probleem voor Ansible. De meest beperkende factor is de gebruiker (layer8) i.m.h.o.

Met alle respect. Leuk dat je Ansible gebruikt om hele datacenters inricht. Maar de vraag was niet over hoe je een datacenter efficiënt kan beheren. Maar feitelijk over het beveiligen van een totale omgeving. Zie onderstaande citaat.

HollowGamer schreef op woensdag 1 augustus 2018 @ 10:28:
Lokaal vind ik dat allemaal niet zo heel erg (zit achter firewall en niet bereikbaar vanaf WAN), maar op een VPS vind ik dat weer een ander verhaal.

Met andere woorden. TS heeft dus een VPS ergens ingericht met enkel de host firewall aan waarvan ik mij kan voorstellen dat het niet lekker zit.

Het gebruik van Ansible voor het geautomatiseerd hardenen en het afdwingen van een security policy van je omgeving is handig en verstandig (Al zal je wel eerst moeten uitzoeken wat en waar deze handelingen moeten plaats vinden). Maar gaat voorbij het punt wat van tevoren nog gedaan had moeten worden:
- In het geval van meerdere VPS-en: Het inrichten van een aparte server met firewall als daar de financiele mogelijkheden daarvoor zijn.
- Als het slechts om een enkele server gaat: Inrichting van Fail2ban om verdacht verkeer te blokkeren.

En alles wat @ppl al zei