Was ist dieses Hyperf -Skelettpaket?
Hyperf liefert offiziell Containerbilder und die Konfigurationsoptionen sind sehr offen. Es ist nicht kompliziert, Hyperf in der Cloud bereitzustellen. Nehmen wir Kubernetes als Beispiel ein und nehmen einige Änderungen an Hyperfs Standard -Skelettpaket vor, damit es auf Kubernetes anmutig ausgeführt werden kann.
Bitte beachten Sie diesen Blog: https://guxi.me/posts/cloudnative-hyperf/
Der Unterschied zum offiziellen Hyperf -Skelett
- Fügen Sie Kubernetes Health Check -Routing hinzu (spezifische Inhalte müssen noch unabhängig von den Benutzern implementiert werden)
- Laut Docker Container Custom Protokolle für STDOUT logetellieren
- Das Ausgabe von JSON -Format in Produktionsumgebungen ist für die Integration von Fluentbit-, Elch- und anderen Sammelwerkzeugen bequem.
- Stellen Sie verschiedene Protokollebenen gemäß Umgebungsvariablen fest
- Verfolgung und metrische Komponenten werden standardmäßig integriert
- Der Standard -Basismodus ist der Basismodus und nur 1 Prozess ist aktiviert. Dieser Modus kann verwendet werden, um die Expansion und das Schrumpfen von Kubernetes-HPA auf Prozessebene zu implementieren.
- Aus den oben genannten Gründen ermöglicht die metrische Komponente unabhängige Prozesse nicht standardmäßig und gibt direkt von der Route aus
- Die Reinigung der Timer wird durchgeführt, wenn Arbeiter endet und einen eleganten Ausgang unter Kubernetes erreicht
- Tracing verwendet Jaeger standardmäßig
- Integrieren Sie League/Flysystem, die Entwicklungsumgebung verwendet standardmäßig das lokale Dateisystem, und andere Umgebungen verwenden den S3 -Treiber standardmäßig.
- Schalten Sie den Fehlerhörer ein
- Das Helm -Diagramm hinzugefügt, das mit einem Klick in K8S eingesetzt wird
- Integrierter Apidog
# helm 2
helm install .helm
# helm 3
helm install hyperf .helm
