Ankündigung

Einklappen
Keine Ankündigung bisher.

Lokale Entwicklungsumgebung mit Windows

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #31
    Zitat von ChristianK
    Vagrant ist eine leichtgewichtige VM, das heist, weniger Speicherverbrauch. Siehe z.B. die Infografik am Ende hier: https://www.scriptrock.com/articles/docker-vs-vagrant
    Nö, Vagrant ist nur ein Provisionierungs- und Verwaltungstool für virtuelle Maschinen, die meisten Boxen, die ich kenne, setzen auf Virtualbox auf. Wenn ich das mal salopp runterbrechen darf, dann unterhaltet ihr euch da über den Unterschied zwischen dem Persistieren von Projektdaten in der VM und dem Synchronisieren über nfs/smb.

    Zitat von jack88
    In meinem Fall verhält es sich so, daß ich in der Firma an einem Win-Pc und einem Win-Laptop arbeite und zuhause mit iMac und Macbook. So müßte ich meine Entwicklungswerkzeuge insgesamt vier mal auf zwei verschiedenen OS einrichten. Außerdem arbeite ich weder mit Mac OS noch mit Windows wirklich gerne. Warum also nicht gleich alle die Entwicklungswerkzeuge einmal in eine schicke Linux-VM packen und bei bedarf auf so viele Rechner kopieren wie nötig.
    Genau die Provisionierung nimmt einem docker oder vagrant ab. Egal, ob docker oder vagrant, du kannst bspw. das image automatisiert neu bauen und musst dafür nur ein Text-File zwischen den Rechnern syncen. Oder das build file ins Repo committen und die Arbeitsumgebung ist bei allen Kollegen die gleiche. Darüber lässt sich auch einfach das komplette Image ziehen, so dass man das auch nicht selbst bauen muss.

    Zitat von jack88
    Wer glaubt, daß sich das alles irgendwie langsam, oder indirekt anfühlt, der sollte es einfach mal selbst ausprobieren.
    Nativ auf dem Hostsystem oder nur mit geringem Overhead (docker unter Linux) zu entwickeln ist schon deutlich performanter/flexibler als mithilfe einer VM. Wenn du deinen Projektcode in der VM persistierst, in der alle Dienste laufen, hast du zwar das Problem der Synchronisierung umschifft, aber gibst einiges an Flexibilität auf. Unit tests unter verschiedenen PHP-Versionen/VMs bspw. Oder ein Update des Host-Systems von debian squeeze auf wheezy. Oder mal eben MariaDB anstelle von MySQL ausprobieren... Im docker-compose file ist das ein Unterschied von einer Zeile. Und damit man nicht jedesmal die Daten synchronisieren muss, einfach ein docker-volume einhängen P.S.: Mit docker machine lässt sich docker auch unter Windows oder Mac betreiben (auch ein Virtualbox Aufsatz, jedoch mit sehr schlanker VM).
    I like cooking my family and my pets.
    Use commas. Don't be a psycho.
    [URL="http://jscouch.de"]Blog[/URL] - [URL="http://coverflowjs.github.io/coverflow/"]CoverflowJS[/URL]

    Kommentar


    • #32
      Genau die Provisionierung nimmt einem docker oder vagrant ab. Egal, ob docker oder vagrant, du kannst bspw. das image automatisiert neu bauen und musst dafür nur ein Text-File zwischen den Rechnern syncen. Oder das build file ins Repo committen und die Arbeitsumgebung ist bei allen Kollegen die gleiche. Darüber lässt sich auch einfach das komplette Image ziehen, so dass man das auch nicht selbst bauen muss.
      Das macht die ganze Sache sicherlich noch angnehmer. Man muss sich allerdings zuerst ein wenig mit Vagrant/Docker beschäftigen bevor man loslegen kann. Da in meinem Fall alle Server ohnehin virtualisiert sind, kann ich auf die automatische provisionierung verzichten. Ich kopiere einfach das Image des Live-Servers, passe es ein wenig an und die Sache ist erledigt.

      Nativ auf dem Hostsystem oder nur mit geringem Overhead (docker unter Linux) zu entwickeln ist schon deutlich performanter/flexibler als mithilfe einer VM.
      Ja, allerdings ist das - zumindest für mich - nicht wichtig. Solange die komplette Entwicklungsumgebung Ruckelfrei und ohne spürbare Verzögerungen läuft, kann ich mit einer etwas schlechteren Performance gut leben. Ob das Hostsytem im Vergleich zur VM nun 100 oder 1000 Requests/Min mehr schafft ist mir während des Entwicklung egal. Der Performacefaktor wird sowieso oft überbewertet. Die meisten Server nutzen ohnenhin nur einen Bruchteil der zur Verfügung stehenden Resourcen. Virtualisierung kostet Performance, aber Virtualisierung hilft gleichzeitig auch die Rechnerresourcen besser zu Nutzen. Nachdem wir bei uns alle Server virtualisiert haben, hat sich die Anzahl der dedizierten Maschinen glatt halbiert und wir haben immer noch Luft nach oben. Ja die Performance hat sich ein wenig verschlechtert, die Backups Nachts brauchen jetzt ein paar Minuten länger

      Wenn du deinen Projektcode in der VM persistierst, in der alle Dienste laufen, hast du zwar das Problem der Synchronisierung umschifft, aber gibst einiges an Flexibilität auf. Unit tests unter verschiedenen PHP-Versionen/VMs bspw.
      Das alles ist möglich, nur das ich dafür dann jeweils eine neue VM brauche. Da sich eine VM per Mausklick klonen läßt, sehe darin kein großes Problem. Bei einem Upgrade von z.B. squeeze auf wheezy gehe ich so vor, dass ich zuerst ein Upgrade-Branch erstelle, dann checke ich diesen Branch in einem neuen Projekt aus und verknüpfe dieses Projekt anschließend mit der neu erstellten Wheezy-VM. So kann ich am demselben Projekt gleichzeitug unter Squeeze und Wheezy arbeiten. Wäre möglich, daß es mit Docker noch deutlich eleganter und performanter geht, das kann ich nicht beurteilen. Ich denke jedoch, daß Docker vielen Entwicklern noch recht unbekannt sein dürfte und deshalb für viele anfangs eine Hürde darstellen könnte. Es geht in erster Linie ja auch um das Konzept an sich und nicht so sehr um die Wahl der konkreten Software dahinter. Wobei Docker in diesem Zusammenhang mit Sicherheit eine sehr spannende Sache ist.

      VG
      Jack
      -

      Kommentar

      Lädt...
      X