Kontinuierliche Integrationswerkzeuge Ressourcen

In der Vergangenheit hatten wir Probleme mit dem Instanzspeicher. Wir hosten es in AWS EC2. Beim letzten Mal, als dies geschah, haben wir die Festplattengröße der Instanz erhöht, aber auch Gitlab so konfiguriert, dass Pipeline-Artefakte und Cache an einen S3-Bucket gesendet werden. Ist es möglich, dasselbe für alle Repository-Inhalte zu tun? Gibt es irgendwelche Leistungseinbußen, die wir berücksichtigen müssen?

Backups sind ein hervorragender Wiederherstellungspunkt, wenn Ihr aktueller Zustand aus irgendeinem Grund "nicht gut" ist. Manchmal möchten Sie jedoch einfach den Zustand der Website in der jüngeren Vergangenheit erneut besuchen. Derzeit erfordert dieser Prozess, dass Sie manuell und einzeln den Code, die Datenbank und die Dateien in die neue MultiDev-Umgebung übertragen.

Wir haben ein CJOC, in dem alle Build-Agenten flüchtig und dockerisiert sind. Wir führen alle Builds auf diesen Docker-Containern aus, deren Basis-Image Amazon Linux ist. Wir verwenden die Kaniko-Pipeline, um neue dockerlose Docker-Images auf diesen containerisierten Build-Agenten zu erstellen. Ich möchte diese von der Kaniko-Pipeline erstellten Images auf Schwachstellen scannen, bevor ich sie in Amazon ECR pushe. Wir verwenden SNYK für lokale Builds, haben auch das SNYK-Plugin für Jenkins ausprobiert, aber es erfordert einen auf einer statischen VM installierten Docker-Daemon (statische VM, die wir nicht verwenden). Wir haben die Docker-in-Docker-Lösung ausprobiert, die in den Cloudbees-Dokumenten bereitgestellt wird, aber das ist in einer Produktionsumgebung nicht machbar, da wir dem laufenden Container Root-Rechte geben müssen. Gibt es andere Lösungen, die Ihnen einfallen? Wenn Sie eine Idee haben, wie man das beheben kann, senden Sie mir eine E-Mail an mayank.sinha@salesforce.com P.S. Ich habe GitHub Actions verwendet und es scannt die Images im Handumdrehen. Ich hoffe, wir können dasselbe in Cloudbees Jenkins tun.