News Googles Kubernetes-Software lockt die Konkurrenz
- Ersteller fethomm
- Erstellt am
- Zur News: Googles Kubernetes-Software lockt die Konkurrenz
thes33k
Lt. Commander
- Registriert
- Apr. 2008
- Beiträge
- 1.258
@fwgdocs
Sehr interessante Idee, ich sage: Zum Teil. Es gibt einfach Vorteile von VMs (Migration), die durch Docker auf baremetal nicht ersetzt werden koennen. MaaS von Ubuntu ist in dem Punkt ja aehnlich und setzt sich auch nicht durch.
Ich denke am Ende wird es so laufen, dass agnostic services massiv ueber VM image mit installiertem Docker laufen werden, waehrend alles andere VM images + Provisionierung werden (DBs etc.).
@MarcDK
Du bringst da Dinge durcheinander. Puppet/Chef/CFEngine/Ansible etc. sind Werkzeuge zur Provisionierung. D.h. es wird immer ein Objekt gegeben, was einen definierten Zustand erreichen soll. Das kann z.B. eine VM sein, die am Ende ein Webserver ist. Das erfolgt ueber Definitionen (bei chef nennt man das cookbook mit recipes, ansible hat playbooks mit tasks etc.).
Docker hat aehnliches als Dockerfile. Darin laesst sich definieren, wie der Container zusammengebaut werden soll. Das ist dem provisioning extrem aehnlich. Das ist aber sehr viel simpler gestaltet als z.B. ein recipe bei chef. Es gibt zum Beispiel keine Weichen (z.B. chef cookbooks muessen moeglichst frueh erkennen, was das OS der Maschine ist, die gerade provisioniert werden soll). Das ist auch nicht notwendig, da das Resultat eben genau definiert ist. Du kannst quasi den Container am Ende auf einen USB stick kopieren und ins RZ tragen. Oder den container auf irgendeinem linux ausfuehren, was lxc container (basis von docker) unterstuetzt. Alles was in dem Container laeuft darf sich vom Konzept nicht fuer die Aussenwelt interessieren (z.B. wer fuehrt mich aus?). Deshalb gibt es auch in diesen Dockerfiles keine Moeglichkeit automatisiert irgendwelche Ordner vom Hostsystem einzubinden. Waehrend des Erstellens des Containers kann man ohne Probleme Files in den Container kopieren, zur Laufzeit geht das aber nicht mehr.
Die grossen Vorteile:
- Der VM typische Overhead ist nur minimal vorhanden
- Ein gebauter Container kann ueberall laufen, wo Docker laufen kann
- Ein Container laeuft ueberall gleich, egal ob im RZ auf Hardware, auf einer VM oder auf dem Ubuntu des App-Entwicklers.
Die grossen Nachteile:
- Man ist quasi auf Wegwerf-Applikationen begrenzt (ergo kannst du z.B. ein wordpress blog mit nginx, php und mysql in einen container tun, es ist aber nicht schlau, weil der container nur ueber sich selber Bescheid weiss. Will man jetzt zwei Nebeneinander laufen lassen, haben beide ihre eigene Datenbank). Das ist eins von den Themen, die Kubernetes versucht zu verbessern, indem Abhaengigkeiten ausserhalb der Container definiert werden.
- Es laeuft nur auf linux. Klingt erstmal nicht so schlimm, wenn man aber mit OS X oder sogar Windows arbeitet wirds hackelig. Da hilft Vagrant momentan etwas, hat aber noch einen bescheuerten Haken mit portforwarding.
- (Noch) keine automatisierte seemless Migration von einem Host zum anderen. Dank der Wegwerfmentalitaet duerfte das eigentlich egal sein, da man ja einfach einen zweiten container anschubsen und den dns namen umziehen kann.
lxc ist uebrigens nichts neues, es setzt sich nur so langsam durch, weil Docker endlich mal werbewirksam ist.
@PaddyG
Naja, das ist halt ein aktuelles DevOps und System Engineering Thema und die wenigsten im Consumer-Bereich duerfte das interessieren. Prinzipiell finde ich es aber lobenswert, dass CB in letzter Zeit gerne mal ueber so etwas berichtet. Aber eine Sache bei dem Heise Artikel: Ich stimme dem Autor absolut nicht zu, wenn er von hoeherem Einstiegsaufwand bei der Konfiguration spricht.
Sehr interessante Idee, ich sage: Zum Teil. Es gibt einfach Vorteile von VMs (Migration), die durch Docker auf baremetal nicht ersetzt werden koennen. MaaS von Ubuntu ist in dem Punkt ja aehnlich und setzt sich auch nicht durch.
Ich denke am Ende wird es so laufen, dass agnostic services massiv ueber VM image mit installiertem Docker laufen werden, waehrend alles andere VM images + Provisionierung werden (DBs etc.).
@MarcDK
Du bringst da Dinge durcheinander. Puppet/Chef/CFEngine/Ansible etc. sind Werkzeuge zur Provisionierung. D.h. es wird immer ein Objekt gegeben, was einen definierten Zustand erreichen soll. Das kann z.B. eine VM sein, die am Ende ein Webserver ist. Das erfolgt ueber Definitionen (bei chef nennt man das cookbook mit recipes, ansible hat playbooks mit tasks etc.).
Docker hat aehnliches als Dockerfile. Darin laesst sich definieren, wie der Container zusammengebaut werden soll. Das ist dem provisioning extrem aehnlich. Das ist aber sehr viel simpler gestaltet als z.B. ein recipe bei chef. Es gibt zum Beispiel keine Weichen (z.B. chef cookbooks muessen moeglichst frueh erkennen, was das OS der Maschine ist, die gerade provisioniert werden soll). Das ist auch nicht notwendig, da das Resultat eben genau definiert ist. Du kannst quasi den Container am Ende auf einen USB stick kopieren und ins RZ tragen. Oder den container auf irgendeinem linux ausfuehren, was lxc container (basis von docker) unterstuetzt. Alles was in dem Container laeuft darf sich vom Konzept nicht fuer die Aussenwelt interessieren (z.B. wer fuehrt mich aus?). Deshalb gibt es auch in diesen Dockerfiles keine Moeglichkeit automatisiert irgendwelche Ordner vom Hostsystem einzubinden. Waehrend des Erstellens des Containers kann man ohne Probleme Files in den Container kopieren, zur Laufzeit geht das aber nicht mehr.
Die grossen Vorteile:
- Der VM typische Overhead ist nur minimal vorhanden
- Ein gebauter Container kann ueberall laufen, wo Docker laufen kann
- Ein Container laeuft ueberall gleich, egal ob im RZ auf Hardware, auf einer VM oder auf dem Ubuntu des App-Entwicklers.
Die grossen Nachteile:
- Man ist quasi auf Wegwerf-Applikationen begrenzt (ergo kannst du z.B. ein wordpress blog mit nginx, php und mysql in einen container tun, es ist aber nicht schlau, weil der container nur ueber sich selber Bescheid weiss. Will man jetzt zwei Nebeneinander laufen lassen, haben beide ihre eigene Datenbank). Das ist eins von den Themen, die Kubernetes versucht zu verbessern, indem Abhaengigkeiten ausserhalb der Container definiert werden.
- Es laeuft nur auf linux. Klingt erstmal nicht so schlimm, wenn man aber mit OS X oder sogar Windows arbeitet wirds hackelig. Da hilft Vagrant momentan etwas, hat aber noch einen bescheuerten Haken mit portforwarding.
- (Noch) keine automatisierte seemless Migration von einem Host zum anderen. Dank der Wegwerfmentalitaet duerfte das eigentlich egal sein, da man ja einfach einen zweiten container anschubsen und den dns namen umziehen kann.
lxc ist uebrigens nichts neues, es setzt sich nur so langsam durch, weil Docker endlich mal werbewirksam ist.
@PaddyG
Naja, das ist halt ein aktuelles DevOps und System Engineering Thema und die wenigsten im Consumer-Bereich duerfte das interessieren. Prinzipiell finde ich es aber lobenswert, dass CB in letzter Zeit gerne mal ueber so etwas berichtet. Aber eine Sache bei dem Heise Artikel: Ich stimme dem Autor absolut nicht zu, wenn er von hoeherem Einstiegsaufwand bei der Konfiguration spricht.
Autokiller677
Fleet Admiral
- Registriert
- Jan. 2009
- Beiträge
- 10.280
Super, und sensible Firmendaten landen damit direkt bei NSA & Co. Da brauchen die gar keine Industriespionage mehr betreiben, wir stellen denen die Daten gleich freiwillig zur Verfügung.MarcDK schrieb:
Ich verstehe den Reiz durchaus und nutze Drive und Dropbox (besonders Drive, Google zeigt da ja wieder richtig, das sie es drauf haben) ebenfalls gerne - aber nur für Unikram, und meine Matheübung kann die NSA gerne sehen. Private Sachen verlassen meinen Rechner nicht.
Gerade als Unternehmen, dass schon einen Server hat, ist es doch ein leichtes, da ownCloud draufzubügeln und die Daten selber unter Kontrolle zu behalten. Und selbst wenn man keinen eigenen Server hat, kann man wenigstens einen hier in D anmieten.
Zuletzt bearbeitet:
MusicJunkie666
Commander
- Registriert
- März 2013
- Beiträge
- 2.757
Und noch einmal: Hier geht es weniger um die Cloud als Online- Speicher. Das kann man leicht selbst realisieren, wenn man die Ressourcen hat, ja.
Aber was ist mit einem Unternehmen, das einmal im Monat sehr, sehr viel Rechenleistung braucht und die restlichen 29/30 Tage so gut wie keine? Die werden sich keine eigene Serverfarm aufstellen. Die werden einen Service wie Amazon AWS nutzen, und rate mal, wie man so einen Service auch nennt: Hochverfügbare, hochflexible Cloud.
Cloud kann vieles bedeuten, deswegen mag ich diesen Begriff nicht. Cloud ist eben nicht nur der Online-Storage, den man als privater kennt.
Aber was ist mit einem Unternehmen, das einmal im Monat sehr, sehr viel Rechenleistung braucht und die restlichen 29/30 Tage so gut wie keine? Die werden sich keine eigene Serverfarm aufstellen. Die werden einen Service wie Amazon AWS nutzen, und rate mal, wie man so einen Service auch nennt: Hochverfügbare, hochflexible Cloud.
Cloud kann vieles bedeuten, deswegen mag ich diesen Begriff nicht. Cloud ist eben nicht nur der Online-Storage, den man als privater kennt.
