So nachdem nun genug Ressourcen da waren liegen die Container einigermaßen. Nun ja, fast. Wir waren ja noch bei der Dev-Umgebung und mal kurz gesagt hatten die vergessen alle File-Shares einzurichten. Eine Applikation ist nie gelaufen, also nicht mal hochgefahren, haben die irgenwie nie mitbekommen und die Datenbank konnte gar nicht laufen bei dem Setup. Nur das haben die uns nicht gesagt und uns überlassen herauszufinden was da nicht läuft.
Also die Aussage, verpackt die in Docker-Container da muss man auf nix achten war völliger Quatsch. Dass die jede Applikation und auch die Datenbank als reguläre Microsoft Wep-App aufgesetzt haben wurde niemals kommuniziert. Also von jeder Applikation gab es drei Instanzen. Und dass man das überhaupt nicht ändern kann (haben die zumindest gesagt, weniger als drei geht nicht) wurde auch nicht kommunizert. Schon klar, dass das zu Problemen führt wenn alle Instanzen gleichzeitig in irgenwelche Logs schreiben wollen und eine Instanz da einen Lock drauf hat. Oder dass das mit der Datenbank niemals klappen kann dass drei Container entweder in die gleichen Data-Files reinschreiben oder jeder Container in seine eigenen was natürlich dazu führt dass man nicht eine sondern drei Datenbanken hat. Haben die aber wohl niemals kappiert und schon gar nicht als notwendig erachtet das zu testen bevor die das als "FERTIG" übergeben haben. Haben uns das überlassen den Fehler zu finden warum das mit der DB nicht geht. Nur darauf würde selbst ein Azubi im ersten Lehrjahr Fachinformatiker drauf kommen, dass das schon vom Prinzip nicht klappen kann. Haben die aber mal schon straightforward komplett so aufgesetzt die DB. Die Superexperten mit so unglaublich viel Erfahurn in Cloud-Migrationen.
Konnte auch nicht klappen weil die Azure-Cloud Health-Checks durchführt über Http und schaut ob die Container antworten. Nur das wird natürlich auf Port 80 bei einem Postgres-Db-Container niemals hinhauen.
Keine Kommentare:
Kommentar veröffentlichen