Frage

Ich denke darüber nach, Vagrant zur Entwicklung von Django -Anwendungen zu verwenden, aber ich bin ein wenig verwirrt und ich bin mir nicht sicher, ob das, was ich tun möchte, überhaupt möglich ist.

Ich habe die lucID32 -Box erfolgreich installiert und eine neue "Instanz" von Vagrant mit einer Vagrantfile, einigen gemeinsamen Verzeichnissen und weitergeleiteten Ports erstellt.

  • Das erste Problem ist, dass mir dies nicht die beste Wahl bei der Arbeit in einem Team erscheint. Wie können wir (ich und andere 10 Entwickler zum Beispiel) die Box teilen, damit jede Änderung geteilt wird? Wenn wir beispielsweise in 6 Monaten PostgreSQL benötigen, muss ich es für 11 -mal nach der Installation von PostgreSQL haben lassen.

  • Wie kann ich Dinge (wie: postgresql, django, this service usw.) zum Starten machen, wenn die Box begonnen hat? Ich glaube nicht, dass ich es ssh und manuell anfangen muss n mal alles n Dinge, die ich jedes Mal brauche.

  • Und schließlich: Ich verstehe nicht gut, ob Dinge wie Puppen- und Küchenchef die manuelle Installation vollständig ersetzen sollen (zum Beispiel durch PIP oder APT-Get). Ist das so?

Vielen Dank.
Und es tut mir leid für schlechtes Englisch. :-)

War es hilfreich?

Lösung

Ich würde sagen, dass Ihre Wahl des Vagranten bereits ein guter Start für das war, was Sie suchen, aber jetzt müssen Sie etwas tiefer in den Koch oder die Puppe eintauchen, um Ihren Bereitstellungsprozess weiter zu automatisieren.

Ich denke, eine gute Wahl in Ihrem Szenenaio wäre, zuerst beides, die VagrantFile und das entsprechende Puppenspiel unter der Versionskontrolle im Rahmen Ihres Projekts zu setzen. Darüber hinaus sollten alle Konfigurationen zu dieser Maschine auch in die Versionskontrolle eingebaut und/oder über eine Art Artefakt -Repository zur Verfügung gestellt werden.

Zweitens, stellen Sie die Regel im Team fest, dass sich ändert (zumindest diese, die länger weiterleben sollten) in die Umgebung müssen eingecheckt werden, wenn sie für die anderen Teammitglieder als bereit gelten.

In Bezug auf Ihre zweite Frage und zurück zu meiner Eröffnung: Puppet (die ich mag) oder Chefkoch sind Ihre Werkzeuge der Wahl und können Sie und Ihre Kollegen in Zukunft viel Arbeit retten. Ich werde hier bei Puppet bleiben, da ich Koch nicht so gut kenne.

Mit Puppet können Sie alles verwalten, was Sie wollen, die Installation von Paketen, die Änderung der Konfigurationen und die Sicherstellung, dass bestimmte Dienste ausgeführt werden, oder im Allgemeinen, dass das System über den Status verfügt, den es sich wünscht. Noch besser, wenn Sie oder ein anderes Team-Mitglied ein paar böswillige Scheunce für seine/ihre Box gemacht haben, können Sie die Änderungen in Ihrem VagrantFile/Puppet-Manifest einfach rollen, eingeben

vagrant destroy && vagrant up

Und die Box kann leicht in den letzten versionierten Zustand zurückgeführt werden.

Nehmen Sie zum Beispiel die folgende Manifestdatei:

package { "mysql-server-5.1":
  ensure => present
}

file { "/etc/mysql/my.cnf":
  owner => "root",
  content => "http://myrepository.local/myProject/configurations/mysql/my.cnf",
  require => Package["mysql-server-5.1"]
}

service { "mysql":
  ensure => running,
  subscribe => File["/etc/mysql/my.cnf"],
  require => File["/etc/mysql/my.cnf"]
}

Was dies tut, ist vor allem den Paketmechanismus des Betriebssystems in Ihrem Kästchen (die Namen im Beispiel nehmen ein aktuelles Ubuntu an), wenn das Paket "MySQL-Server-5.1" installiert ist und falls es nicht installiert wird es. Durch das Attribut "Erforderliche" wird die zweite Anweisung nach dem ersten ausgeführt (und nur, wenn es funktioniert), wodurch die MySQL Legen Sie in denselben Ordner wie die VagrantFile ein und sind dann in der Box unter /Vagrant erhältlich). Der letzte Schritt, der erneut ausgeführt wird, wenn die Änderung der Konfiguration funktioniert hat, wird sicherstellen, dass der "MySQL" -Dienst in Betrieb ist oder neu gestartet wird, wenn er bereits ausgeführt wurde, wenn die Konfiguration geändert wurde.

Jetzt können Sie dieses Manifest in Ihrer VagrantFile anschließen:

Vagrant::Config.run do |config|

  config.vm.box = "lucid32"
  config.vm.box_url = "http://files.vagrantup.com/lucid32.box"

  config.vm.define "node1" do |cfg|
    cfg.vm.network "10.23.5.11"
    cfg.vm.provision :puppet do |puppet|
      puppet.manifests_path = "manifests"
      puppet.manifest_file = "node1.pp"
    end
  end
end

Bei allen Änderungen neben den "Versuchs-Out", die in der Umgebung wie dieser vorgenommen wurden, ist allen Team Mebers garantiert, dasselbe Setup einfach und reproduzierbar ist, nur an den Fingerspitzen.

Ich persönlich mag es, Sachen auf der Box von Hand auszuprobieren. Wenn ich das richtige Setup und die richtige Konfiguration gefunden habe, übersetzen Sie es in ein Puppenmanifest, um sie zu haben, wenn sie für die spätere Verwendung und gemeinsame Nutzung mit Teammitgliedern bereit sind.

Da Puppet (und auch Chef auch Koch) fast alles verwalten kann, was Sie benötigen (Benutzer, Cron -Jobs, Pakete, Dienste, Dateien, ...), ist dies eine gute Wahl für genau solche Probleme, und Sie haben den Vorteil, überhaupt in der Lage zu werden, verwenden zu können Die Konfigurationen zur Bereitstellung von Staging- oder Testumgebungen später, wenn Sie möchten. Es gibt viel mehr Optionen mit Puppenspiel und durchlesen der Sprachführer Sollte Ihnen eine gute Idee geben, was Sie mehr damit machen können.

Hoffe ich könnte helfen :)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top