Terraform-provider-aws: Funktionsanforderung: Stoppen, Instanz bei Benutzerdatenaktualisierung nicht zerstören

_Dieser Kommentar wurde ursprünglich von @JeanMertz als https://github.com/hashicorp/terraform/issues/1887#issuecomment -100605772 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Das ist interessant. Ich glaube nicht, dass Terraform derzeit einen Stopp/Start-Zyklus hat, nur zerstören oder nicht zerstören.

Ich sehe viel Wert für diesen Anwendungsfall (da wir auch stark Benutzerdaten verwenden), aber ich sehe auch, dass dies kompliziert wird.

Wenn ich mich nicht irre, wird auf AWS eine Instanz ohne ein EBS-gestütztes Speichergerät einfach den Speicher zurücksetzen, sodass das Stoppen/Starten in diesem Fall das gleiche Ergebnis wie eine Zerstörung hätte.

Hier ist die Liste der Eigenschaften, die Sie mit AWS im angehaltenen Zustand ändern können:

Sie können die folgenden Attribute einer Instanz nur ändern, wenn sie gestoppt ist:

• Instanztyp
• Benutzerdaten
• Kernel
• RAM-Disk

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -101095776 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Dieses spezielle Problem ist also kein Problem mit GCE, da Sie Metadaten ohne forceNew aktualisieren können. Es gibt jedoch ein ähnliches Problem, wenn Sie Zone / Scopes ändern möchten, ohne die Daten auf Ihrer Festplatte zu verlieren.

Ich gehe dabei so vor, dass ich in jeder Situation, in der der Inhalt der Festplatte in irgendeiner Weise wertvoll ist, eine separate Datenträgerressource verwendet. Für Datenbanken trifft dies offensichtlich zu, aber typischerweise ist die Festplatte in einem Knoten eines lastausgeglichenen Clusters entbehrlich. Mit einer separaten Festplatte kann Terraform die Instanz neu erstellen, ohne die Festplatte zu verlieren (da die Festplatte nicht neu erstellt wird). Ich glaube, dies entspricht einem Neustartzyklus.

_Dieser Kommentar wurde ursprünglich von @Pryz als https://github.com/hashicorp/terraform/issues/1887#issuecomment -138493574 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Was ist, wenn wir nichts tun, wenn wir user_data aktualisieren?

Wenn Sie Terraform und eine Konfigurationsverwaltungslösung verwenden, werden die Benutzerdaten die meiste Zeit nur zum Beispiel beim Bootstrapping verwendet. Wenn Sie also Benutzerdaten ändern, gilt dies wahrscheinlich nur für neue Instanzen, nicht für aktuelle.

_Dieser Kommentar wurde ursprünglich von @jwaldrip als https://github.com/hashicorp/terraform/issues/1887#issuecomment -138559228 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Nicht zustimmen. Ich verwende CoreOS in der Produktion und verwalte alles mit Benutzerdaten. Sogar bestehende Instanzen.

_Dieser Kommentar wurde ursprünglich von @Pryz als https://github.com/hashicorp/terraform/issues/1887#issuecomment -138591063 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ok, wie wäre es also mit einem Argument, um die Strategie zu spezifizieren? (Neustart, Neu erstellen, Keine)

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -138654976 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Zum Vergleich: Für die Metadaten der Google-Compute-Instanz haben wir mit aktualisierbaren Metadaten begonnen (dh die Instanz nicht neu erstellen, sondern die Metadaten aktualisieren, damit die Instanz die neuen Werte sehen kann). Dies ist tatsächlich sehr nützlich, da Sie auf dem Metadatenserver hängend abrufen können, was bedeutet, dass Sie einen Agenten in Ihrer VM ausführen können, der über Änderungen an den Metadaten benachrichtigt wird. Auf diese Weise können Sie die VM steuern (z. B. neue Anwendungssoftware einführen), indem Sie die Metadaten aktualisieren. Ich weiß nicht, ob AWS Sie das tun lässt, aber ich gehe davon aus, dass es wirklich nützlich ist.

Wenn Sie jedoch keinen solchen Agenten haben und das einzige, womit Sie arbeiten müssen (wenn Sie eine wirklich deklarative Knotenkonfiguration durchführen möchten), das Startup-Skript (Benutzerdaten auf AWS) ist, dann möchten Sie das Startup-Skript ändern zu Erstellen Sie die Instanz neu, damit das Startskript erneut ausgeführt wird. Für viele Leute, insbesondere zustandslose Server, ist das gut genug. Die einzigen Kosten sind die Zeit, die benötigt wird, um die Instanz neu zu erstellen (der Agent ist sofort verfügbar).

Also habe ich ein metadata_startup_script-Feld in der Google-Instanz hinzugefügt, das mit metadata.startup-script identisch ist, außer dass es ForceNew ist. Man darf nicht beide angeben. Der Benutzer kann daher wählen, ob er das ForceNew-Verhalten haben möchte oder nicht.

Sie könnten dasselbe für aws_instance tun: Verwenden Sie ein updateable_user_data-Feld, das nicht ForceNew war, damit Benutzer Änderungen daran vornehmen können, ohne die Instanz neu zu erstellen, und Agenten innerhalb der VM ausführen, um diese Änderungen zu übernehmen. Und behalten Sie das aktuelle user_data-Feld für den einfachen Nicht-Agent-Fall bei.

_Dieser Kommentar wurde ursprünglich von @Pryz als https://github.com/hashicorp/terraform/issues/1887#issuecomment -138859642 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich mag die Idee, zwei verschiedene user_data-Felder zu haben, da es zwei völlig unterschiedliche Möglichkeiten gibt, Instanzen zu verwalten.

_Dieser Kommentar wurde ursprünglich von @FergusNelson als https://github.com/hashicorp/terraform/issues/1887#issuecomment -149802063 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich denke, es wäre schön, Befehlszeilenoptionen im Allgemeinen zu stoppen und zu starten. Der Anwendungsfall wäre eine Staging- oder Testumgebung, die nicht ständig benötigt wird; Anstatt die Umgebung jedes Mal zu zerstören und neu zu erstellen, wenn dies erforderlich ist, wäre es schön, dies tun zu können

terraform stop
terraform start

Und lassen Sie Terraform die Maschinen in der richtigen Reihenfolge in Bezug auf das Abhängigkeitsdiagramm starten.

_Dieser Kommentar wurde ursprünglich von @c4milo als https://github.com/hashicorp/terraform/issues/1887#issuecomment -150636511 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Soweit ich weiß, besteht der einzige Zweck von Cloud-Init- oder Benutzerdatenskripten darin, Instanzen frühzeitig zu initialisieren. Aus dieser Perspektive ist es möglicherweise nicht sinnvoll, Instanzen erneut bereitzustellen oder neu zu konfigurieren, da Tools wie Puppet, Chef, Ansiable und Salt dafür vorgesehen sind. Terraform wurde als Möglichkeit zum Erstellen und Zerstören von Infrastrukturressourcen konzipiert, und die Unveränderlichkeit von Ressourcen ist allgegenwärtig. Vielleicht kann @mitchellh hier etwas mehr Licht ins Dunkel bringen.

_Dieser Kommentar wurde ursprünglich von @jwaldrip als https://github.com/hashicorp/terraform/issues/1887#issuecomment -150648445 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Sicher, das ist in einigen Fällen der Fall. Aber in unserem Fall verwenden wir Core-OS
und verwenden Sie Benutzerdaten, um die Maschinen zu booten. Wir benutzen NIE Marionette, Koch,
salt usw., um die Instanz weiter zu instanziieren. Vielleicht ist das schlecht
Praxis, aber ich weiß, dass sich Benutzerdaten ändern können. Außerdem wir
können unsere etcd-Instanzen nicht zerstören, um neue Benutzerdaten bereitzustellen, wie wir es tun
riskieren, das Quorom zu verlieren.

Am Freitag, 23. Oktober 2015 um 11:13 Uhr, Camilo Aguilar [email protected]
schrieb:

Soweit ich verstehe, ist der einzige Zweck von Cloud-Init- oder Benutzerdaten-Skripten
ist die frühe Initialisierung von Instanzen. Aus dieser Perspektive mag es
Es macht keinen Sinn, es als Möglichkeit zum erneuten Bereitstellen oder Neukonfigurieren von Instanzen zu verwenden
denn dafür sind Tools wie Puppet, Chef, Ansiable und Salt da.
Terraform wurde als eine Art des Erschaffens und Zerstörens konzipiert
Infrastrukturressourcen und Ressourcenunveränderlichkeit sind allgegenwärtig.
Vielleicht kann @mitchellh https://github.com/mitchellh noch mehr loswerden
Licht hier.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/hashicorp/terraform/issues/1887#issuecomment -150636511
.

Jason Waldrip
m: 646-460-5959
e: [email protected]
http://www.facebook.com/jason.waldrip
http://www.linkedin.com/in/jasonwaldrip

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -150649603 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Es ist keine schlechte Praxis, es funktioniert sehr gut und wird immer häufiger.

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -150662423 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Haben Sie versucht, eine separate Datenträgerressource zu verwenden? Wenn Sie auch eine statisch zugewiesene IP verwenden, sollte das meiner Meinung nach einem Neustart entsprechen?

_Dieser Kommentar wurde ursprünglich von @JamiKarvanen als https://github.com/hashicorp/terraform/issues/1887#issuecomment -152194919 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich habe den gleichen Anwendungsfall wie @jwaldrip. Bei Verwendung von CloudFormation von AWS werden die user_data aktualisiert, die Instanzen jedoch nicht neu erstellt oder neu gestartet. Amazon stellt ein cnf-hup-Skript bereit, das Änderungen der Benutzerdaten in Instanzen erkennt und sie entsprechend aktualisiert. Daher wäre es großartig, die Benutzerdaten nur mit Terraform aktualisieren und AWS die Aktualisierung überlassen zu können.

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -152232461 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Upgrade auf "Es ist keine schlechte Praxis, es funktioniert sehr gut, wird immer häufiger verwendet und wird von AWS und Google aktiv gefördert" :)

_Dieser Kommentar wurde ursprünglich von @manojlds als https://github.com/hashicorp/terraform/issues/1887#issuecomment -165428494 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Keine Bewegung dazu?

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -168040430 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich denke, es sollte eine ziemlich einfache PR sein, ein neues Ressourcenattribut zum Steuern von Benutzerdaten auf nicht zwangsweise neue Weise hinzuzufügen. Wenn jemand entsprechend motiviert wäre :)

_Dieser Kommentar wurde ursprünglich von @yogin als https://github.com/hashicorp/terraform/issues/1887#issuecomment -191015474 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich wäre sehr daran interessiert, zu verhindern, dass Instanzen neu erstellt werden, wenn sich Benutzerdaten ändern. Ich verstehe, dass einige Leute es für verschiedene Zwecke verwenden, und ich mag die Idee, eine Strategie anzugeben (neu erstellen, keine, ...).

In unserem Fall verwenden wir die Benutzerdaten nur, um neue Instanzen zu booten, später übernimmt chef und erledigt den Rest, aber gelegentlich erhält die Benutzerdatenvorlage ein kleines Update, und wenn ich es vermeiden könnte, Instanzen neu erstellen zu müssen, würde ich das tun Sei unglaublich!

_Dieser Kommentar wurde ursprünglich von @mcortinas als https://github.com/hashicorp/terraform/issues/1887#issuecomment -198468223 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Keine Bewegung dazu?

_Dieser Kommentar wurde ursprünglich von @modax als https://github.com/hashicorp/terraform/issues/1887#issuecomment -219944854 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich bin kein Terraform-Entwickler, aber ich habe mir den aktuellen Terraform-Code kurz angesehen und es scheint, dass die einzig mögliche Lösung ohne (große) Terraform-Core-Änderungen darin bestehen könnte, ein weiteres Attribut wie live_user_data hinzuzufügen (da der ForceNew-Wert so weit nicht vom Kontext abhängen kann wie gesagt). Der Code kann immer noch chaotisch werden, weil zwei Attribute dasselbe ändern (in Bezug auf die Diff-Berechnung). Daher bin ich mir nicht sicher, ob das Terraform-Team eine solche PR akzeptieren würde.

_Dieser Kommentar wurde ursprünglich von @sparkprime als https://github.com/hashicorp/terraform/issues/1887#issuecomment -220068197 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

@modax Wie ich weiter oben im Thread sagte, ist dies genau das, was die google_compute_instance tut, und es funktioniert gut

_Dieser Kommentar wurde ursprünglich von @markmaas als https://github.com/hashicorp/terraform/issues/1887#issuecomment -224507714 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Durch das Zerstören und Neuerstellen von Instanzen, wenn sich die Benutzerdaten ändern, kann ich entweder:

• Benutzerdaten nicht verwenden (und damit Cloud-Konfiguration)
• Benutze Terraform nicht (bedeutet, ich muss Wolkenbildung lernen: ugh)

Da Cloud-Config immer häufiger verwendet wird, um das anfängliche Bootstrapping einer Instanz durchzuführen, würde ich denken, dass dies keine "Verbesserung" mehr ist, sondern eher in Richtung "Blockierung".

_Dieser Kommentar wurde ursprünglich von @cheungpat als https://github.com/hashicorp/terraform/issues/1887#issuecomment -224561306 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Wenn Sie nicht möchten, dass Ihre Instanz neu erstellt wird, wenn sich user-data ändert, können Sie versuchen, diesen Schlüssel in ignore_changes .

_Dieser Kommentar wurde ursprünglich von @br0ch0n als https://github.com/hashicorp/terraform/issues/1887#issuecomment -233416285 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich stimme @cheungpat zu, dass ignore_changes wahrscheinlich dieses Ticket behandelt (sobald #5627 fertig ist)

_Dieser Kommentar wurde ursprünglich von @gdubicki als https://github.com/hashicorp/terraform/issues/1887#issuecomment -263675038 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Ich bestätige, dass das, was @cheungpat vorschlägt, eine gute Problemumgehung ist. Wenn Sie den GCE-Anbieter verwenden, verwenden Sie diesen Code, um Änderungen am Startskript zu ignorieren:

lifecycle {
  ignore_changes = ["metadata_startup_script"]
}

Aber es wäre noch besser, wenn Sie es einmal global festlegen könnten - nicht in jeder Ressource vom Typ google_compute_instance . Ist das möglich?

UPDATE: AFAIK ist es nicht möglich und Sie können nicht einmal eine Variable verwenden, um ignore_changes . :( Siehe #10730.

_Dieser Kommentar wurde ursprünglich von @kirkmadera als https://github.com/hashicorp/terraform/issues/1887#issuecomment -264654270 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Dies gilt auch für die Größenänderung von AWS-Instanzen. Am Ende gehen wir in den AWS-Administrator, stoppen die Instanz, ändern den Instanztyp und starten sie dann erneut. Dann aktualisieren wir die Terraform-Konfigurationen, damit sie dem neuen Instance-Typ entsprechen, und führen Terraform Apply aus, wodurch der Terraform-Status mit der neuen Größe synchronisiert wird.

Idealerweise würden wir einfach die Größe von Terraform ändern. Die Größenänderung eines AWS-Servers ändert auch seine öffentlichen und privaten IPs. Das Ausführen der Größenänderung von Terraform aus würde es uns ermöglichen, bei Bedarf auch DNS sofort zu ändern, anstatt darauf zu warten, dass wir Terraform ausführen, nachdem die Größenänderung abgeschlossen ist.

_Dieser Kommentar wurde ursprünglich von @stack72 als https://github.com/hashicorp/terraform/issues/1887#issuecomment -282127593 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Liebe Freunde, jetzt, da ich das Problem der Änderung von instance_type angegangen bin und es Teil von Terraform 0.8.8 sein wird, werde ich mit dem Prototyping dazu beginnen

Paul

_Dieser Kommentar wurde ursprünglich von @cnoffsin als https://github.com/hashicorp/terraform/issues/1887#issuecomment -294035120 geöffnet. Es wurde im Rahmen des Providersplits hierher migriert. Der ursprüngliche Kommentar ist unten._

Der Anwendungsfall für mich hier ist, dass ich Typänderungen in AWS an einem Cloudera-Cluster vornehmen muss.

Die Ingenieure haben es ordnungsgemäß heruntergefahren, damit ich die Änderung vornehmen konnte.

Ich möchte den Typ ändern, aber LASS sie aus. Damit sie sie in die richtige Reihenfolge bringen können.

Irgendwelche Neuigkeiten zu dieser Funktionsanfrage? Ich bin in der gleichen Position und diese Funktion (Stopp/Start beim Ändern von Benutzerdaten in AWS) wird unsere Hot-Deployment-Muster stark lindern.

Wenn ich das richtig verstehe, dann ist die TL;DR bisher dies:

Die Verwendung ignore_changes (obwohl gut zu beachten) erfüllt nicht den Anwendungsfall, Terraform tatsächlich die user_data einer vorhandenen Ressource verwalten zu lassen, ohne sie neu zu erstellen. Mit anderen Worten, der gewünschte Arbeitsablauf lautet „stoppen, aktualisieren, starten“ statt „zerstören, aktualisieren, erstellen“.

Wenn sich bei ignore_changes = ["user_data"] der Inhalt von user_data ändert, ignoriert TF ihn einfach – was für Hosts in Ordnung wäre, die user_data nur für die Bereitstellung beim ersten Start verwenden. Aber wenn user_data Ihr Mechanismus zum Aktualisieren der Konfiguration eines laufenden Hosts ist (und neu startet, anstatt neu zu erstellen), werden die Änderungen nicht übertragen.

Habe ich Recht, dass der Hauptblocker ist, dass Terraform derzeit nicht (AFAIK) die Verwaltung des Up/Down-Zustands einer EC2-Instance unterstützt (um „Stopp, Update, Start“ zu erreichen)?

Das Endziel für mich ist es, den ec2-Instance-Typ ändern zu können und ihn von Terraform ändern zu lassen, anstatt ihn zu zerstören und neu zu erstellen. Ich glaube die neuste Version tut das eigentlich schon.

Ich brauche es.

Das wäre schön

Ich möchte meine Stimme abgeben. Bitte markieren Sie diese Ressourcen nicht mehr als geändert. Wenn Sie wirklich müssen, könnten Sie auf ein Attribut zurückgreifen, um dieses Verhalten umzuschalten, aber ich argumentiere, dass ein Benutzer eine Ressource absichtlich verderben kann, wenn er sie ändern muss. Wie immer geht es hier um die Arbeit mit Menschen, obwohl ich die Starrheit liebe, habe ich festgestellt, dass sie zusammenbricht, wenn die Arbeit verteilt wird und ein paar Monate vergangen sind. Sie lernen oder ändern Dinge und möchten den Code entsprechend anpassen, wahrscheinlich etwas, das mit einem anderen Knoten zu 100 % verifiziert ist, aber die Änderung zu einem späteren Zeitpunkt planen. Derzeit bestand unsere Strategie darin, einen riesigen Kommentarblock zu hinterlassen, aber es fühlt sich chaotisch an.

FWIW, ich brauchte etwas Ähnliches und landete bei diesem Skript, um die Instanz zu stoppen und das zu tun, was wir außerhalb von Terraform brauchten. Könnte jemandem von Google helfen, hier für aws zu landen.

terraform apply -auto-approve \
    -var "instance_name=${INSTANCENAME}" \
    -var "environment=${DEPLOY_ENV}" \
    -var "security_group=sg-0a9cf274" \
    -var "ami_name=${AMINAME}" \
    -var "vpc_id=${VPCID}" \
    -var "keypair_name=bastion.${DEPLOY_ENV}"

....................

INSTANCEID=`aws ec2 describe-instances --filters "Name=tag:Name,Values=${INSTANCENAME}" \
            --query "Reservations[0].Instances[0].InstanceId" --output text | tail -1`

if [[ "${INSTANCEID}" == "" ]]; then
    echo "There was a problem getting instance id from AWS. Exiting."
    exit 1
fi

aws ec2 stop-instances --instance-ids ${INSTANCEID}

Ich bin mir nicht sicher, wie mein Kommentar zur Diskussion beiträgt, aber ich bin auf dieses Problem gestoßen, nachdem ich mit user_data Änderungen konfrontiert wurde. Scheint es irgendwie "von außen" (?) geändert zu haben, AWS hat vielleicht über Nacht etwas getan? Keine Ahnung.

Ich verwende und verlasse mich nicht auf user_data . Ich habe es nicht unter meinen aws_inctance -Ressourcen usw. deklariert. Bei mir funktionierte alles einwandfrei ( terraform plan und Remote-Status). Ich habe weder terraform noch Anbieter aktualisiert. Nach dem Ausführen terraform plan Heute sind die meisten meiner EC2s aufgrund einer user_data -Änderung für die Neuerstellung markiert. Sogar wenige EC2 die gestoppt werden 🤷‍♂️

Am Ende habe ich ignore_changes gemacht, habe aber keine Ahnung, was passiert ist.

@rmldsky das klingt erschreckend. Bitte reichen Sie ein separates Problem/einen separaten Fehler ein und verweisen Sie auf diesen.

Bitte beachten Sie, dass es derzeit 46 Stimmen für diese Ausgabe auf https://github.com/hashicorp/terraform/issues/1887 gibt

Wäre hilfreich, haben wir aktuelle Informationen dazu?

Wie ist das immer noch nicht ein Ding? Dies ist einer der wenigen Orte, an denen CloudFormation Terraform weit überlegen ist. Eine Änderung der Benutzerdaten erfordert KEINE Zerstörung einer Instanz, und Terraform sollte auf Fehler auf der Seite der Nichtzerstörung aktualisiert werden.

Ich habe hier das gleiche Problem - Anwendungsfall:
Wir haben eine Reihe von Systemen, die nach einem automatisierten Zeitplan (basierend auf Tags) gestoppt/gestartet werden, und wir verwenden <persist>true</persist> , damit Benutzerdaten auf jedem dieser Starts ausgeführt werden können, um verschiedene Aufgaben auszuführen. Wenn wir diese Aufgaben hinzufügen, entfernen oder anpassen müssen, ist eine Aktualisierung der Benutzerdaten erforderlich. Wenn wir dies derzeit über Terraform (ohne manuelle Interaktion) tun, wird die Instanz wie oben erwähnt zur Zerstörung markiert.

Die manuelle Umgehung besteht darin, die Benutzerdaten außerhalb von Terraform selbst zu aktualisieren, und dann wird beim nächsten Anwenden/Planen der Status übereinstimmen, sodass keine Zerstörung erforderlich ist. Dies ist in vielen Instanzen mühsam und zeitaufwändig, insbesondere wenn Sie den Vorlagenanbieter verwenden, um Werte in die Benutzerdaten einzugeben (wir tun ...), da Sie diese Werte auch per Skript füllen oder manuell anpassen müssen, bevor Sie sie auf jede Instanz anwenden .

Ich würde denken, dass dies ähnlich wie der oben erwähnte Änderungsinstanztyp funktionieren sollte - Instanz stoppen (falls ausgeführt), Benutzerdaten ändern, Instanz starten (falls sie vor der Änderung ausgeführt wurde).

Irgendwelche Updates dazu? Gibt es irgendetwas, was wir tun könnten, um mit diesem Problem voranzukommen?

Warum können Sie nicht einfach die Option lifecycle { ignore_changes = [ what-to-ignore ] } verwenden?
https://www.terraform.io/docs/configuration/resources.html#ignore_changes

@Andor , weil wir die Benutzerdatenaktualisierungen anwenden möchten. Das Update muss die Instanz nicht zerstören.

@et304383 Bist du sicher, dass es funktioniert? Wegen Benutzerdaten (soweit ich weiß) nur zur Initialisierung verwendet und sonst nichts.

Unterm Strich wird das Aktualisieren von Benutzerdaten unterstützt, ohne die Instanz zu zerstören (sie muss während des Updates einfach angehalten werden). Terraform sollte dies wie CloudFormation unterstützen.

Ich stimme @et304383 zu. Benutzerdaten werden von cloud-init bei _jedem_ Start ausgewertet und können aktualisiert werden, wenn der Host gestoppt wird. Es ist selten, dass es über den _ersten_ Start hinaus nützlich ist, aber es gibt einige Anwendungsfälle (zB Vyos Runtime Config).

@boweeb das stimmt nicht. Es läuft nur beim ersten Start. Es wird ausgeführt, wenn Sie eine neue Instanz über ein AMI für Linux erstellen, und nur für Windows, wenn Sie die Ausführung vor dem Erstellen des AMI planen:

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html#user -data-execution

@et304383 danke, dass du das angesprochen hast, das sollte geklärt werden. Sie haben Recht: Windows führt Cloud-Init nicht bei jedem Start aus. Dies ist ein implementierungsspezifisches Problem.

Auf zumindest den meisten Linux-AMIs (RedHat/CentOS und Amazon Linux bestätigt) ist cloud-init so konfiguriert, dass es bei jedem Start ausgeführt wird und auswertet, welche Schritte es ausführen muss. Zum Beispiel läuft runcmd nur beim ersten Booten und bootcmd läuft (etwas früh im Bootprozess) bei _jedem_ Booten.

https://cloudinit.readthedocs.io/en/latest/topics/examples.html#run -commands-on-first-boot

Jawohl. Der Fokus liegt hier darauf, dass Benutzerdaten nur einmal laufen. Das Aktualisieren auf einer vorhandenen Instanz löst nicht seine Ausführung aus.

Zusammenfassung/Anmerkungen von oben -

• Die AWS-API unterstützt die Aktualisierung von Benutzerdaten (wenn sich die Instanz in einem angehaltenen Zustand befindet)
• Andere AWS-Instance-Updates unterstützen das Stoppen, Aktualisieren und Starten von Instances, Beispiel: Instance-Typ
• Instanz-Benutzerdaten können dynamisch sein, indem Daten aus state/tfvars und der TF-Vorlagenfunktionalität verwendet werden. Dies macht die manuelle Aktualisierung über API/GUI mit zunehmender Anzahl von Instanzen viel schwieriger.
• Sowohl Windows als auch Linux können so konfiguriert werden, dass Benutzerdaten bei jedem Start oder nach Zeitplan ausgeführt werden. Es sind Komplexitäten und Arbeit erforderlich, aber es ist für beides möglich.
• Es gibt verschiedene Bereitstellungsstile und einige beinhalten die Verwendung von Benutzerdaten für mehr als nur die Initialisierung des ersten Starts (Multi-Boot-Starts, Update beim Start (OS, AV), Benachrichtigung/Aktion beim Start). Obwohl dies situativ ist, handelt es sich dennoch um eine unterstützte und dokumentierte Funktion von AWS.

Ist es angesichts des oben Gesagten nicht sinnvoll, diese Funktionalität in den Anbieter aufzunehmen?

Da es mehrere Anwendungsfälle gibt, könnte dies mit einem zusätzlichen Argument implementiert werden, wie zum Beispiel:
'user_data_update_action'
Beispieloptionen: neu starten, neu erstellen, ignorieren

Um die aktuelle Funktionalität beizubehalten, könnte dies standardmäßig auf "Neu erstellen" eingestellt sein und dann denjenigen, die es benötigen, erlauben, sich von dort aus anzupassen.

@phinze , @bflad oder jemand anderes bei Hashicorp, könnten Sie bitte jemanden intern anpingen, um sich das anzusehen. Es ist jetzt seit fast 2 Jahren geöffnet ...

Das wäre auch sehr hilfreich für mich.

++^
Dies wäre sehr hilfreich. Ich habe derzeit dieses Problem und brauche eine Problemumgehung, damit meine benötigten Verzeichnisserver nicht zerstört werden.
Ich bin mir auch nicht sicher, wie die Benutzerdaten nicht mehr synchron sind.

Jawohl. Der Fokus liegt hier darauf, dass Benutzerdaten nur einmal laufen. Das Aktualisieren auf einer vorhandenen Instanz löst nicht seine Ausführung aus.

Dies ist nicht ganz richtig. Um zu verstehen, warum, ist es wichtig, den Unterschied zwischen Benutzerdaten zu berücksichtigen und was ein bestimmtes Bild mit den Benutzerdaten _macht_. Dies gilt für viele verschiedene Clouds, nicht nur für AWS.

Wenn Sie in AWS Benutzerdaten angeben, werden diese auf dem Metadaten-Endpunkt für die Instance verfügbar. Die Tatsache, dass cloudinit nicht auf Updates reagiert, ist völlig orthogonal zu der Möglichkeit, diese Konfiguration beim Anbieter zu aktualisieren - es sind viele Images im Einsatz, die cloudinit überhaupt nicht verwenden und stattdessen andere Arten von Konfigurationsdaten über Benutzerdaten weitergeben. Ein solches Beispiel sind moderne Windows-Images, die ec2config anstelle von cloudinit verwenden.

_Jedoch_ verfügt Terraform nicht über das Konzept von und Update, das in diesem Zusammenhang einen Neustart einer Ressource erfordert - aber es sollte wahrscheinlich lernen, dies zu tun, und zulassen, dass es aktiviert wird, wo es sinnvoll ist.

Ich denke, das ist fair, aber mein Punkt ist, dass ein Administrator sich dieses Kontexts bewusst ist und wahrscheinlich nur Änderungen aufzeichnen möchte, die für den nächsten Aufruf einer Instanz vorgesehen sind, aber ich habe begonnen, Lebenszyklusregeln zu verwenden, um diese Änderung zu ignorieren, was zu meiner Verwendung passt Fall. An dieser Stelle würde ich es vorziehen, wenn Sie sich darauf konzentrieren, Ihren Rückstand zu bereinigen.

Würde ein PR zum Hinzufügen einer bestimmten aws_instance_user_data -Ressource wahrscheinlich akzeptiert werden?

Die Aktualisierung instance_type (was auch einen ähnlichen Stop-Update-Start-Zyklus erfordert) wird seit einiger Zeit unterstützt: https://github.com/terraform-providers/terraform-provider-aws/issues/4838

Könnten wir hier eine ähnliche Lösung annehmen? Wir mussten einen anderen Weg finden, um die Instanzkonfiguration zu aktualisieren (über den Anhang des SSM-Dokuments), hauptsächlich wegen dieser Einschränkung in Terraform für user_data .

BEARBEITEN: Für den Kontext haben wir eine proprietäre Anwendung eines Drittanbieters, die eine Instanzkonfiguration über user_data übergeben muss, und alle Aktualisierungen dieser Konfiguration sind sehr problematisch. Diese Anwendung kann auch keinen Instanzaustausch tolerieren, da sie an eine bestimmte Instanz-ID für die Lizenzaktivierung gebunden ist.

Jawohl. Der Fokus liegt hier darauf, dass Benutzerdaten nur einmal laufen. Das Aktualisieren auf einer vorhandenen Instanz löst nicht seine Ausführung aus.

Diese Aussage trifft auf AWS nicht zu. Es ist möglich, ein Tag persist hinzuzufügen, das sicherstellt, dass Benutzerdaten bei jedem Start ausgeführt werden.

Beispiel für Benutzerdaten mit dem Tag persist :

<script>
net start codedeployagent
net start AmazonCloudWatchAgent
</script>
<persist>true</persist>