A Metaphor is a suite of demo microservice applications to demonstrate how an application can be integrated into the Kubefirst platform following best practices. The demo applications consists of a Metaphor frontend, Metaphor Go API, and Metaphor NodeJS API.
The Metaphor applications provide a demonstration space for application best practices in a tangible way that's easy to apply to other projects. When engineers discover good patterns to use in other projects, they can add that new idea in the most straightforward way possible to the Metaphor applications as well. By doing so our engineering team can fully engage with the best application approaches.
The Metaphor applications come with complete CI/CD processes including automated builds, container Helm chart creation, container
and Helm chart publishing, linting, tests, GitOps deployments to
release management, version management, and hotfixes. It serves as an excellent proving ground for changes to the CI/CD layer.
When a new version of our CI is needed, it's best to adopt that new version of the CI in a Metaphor application first. Run through the adjustments to your automation and test it through all of your environments and kubernetes clusters without impacting the applications that your engineers and users depend on.
The Metaphors applications are multi-instance load balanced applications. It's deployed to the
production namespaces in your
The Kubernetes manifests produced by the Metaphors applications CI include a working example of a Kubernetes deployment with downstream ReplicaSet and pods, a service account with a security context used, a service to make the application available to the cluster, and an Ingress to make the service available outside the cluster.
The Ingress manifest demonstrates integration with our automated approach to DNS management, load balancer management, and TLS/SSL certificate creation and renewal.
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx # Change the next line to "letsencrypt-staging" while testing adjustments, change to "letsencrypt-prod" after confirming LE certificate was issued cert-manager.io/cluster-issuer: "letsencrypt-prod" name: metaphor labels: run: metaphor spec: rules: - host: metaphor-development.your-company.io http: paths: - backend: serviceName: metaphor servicePort: 3000 path: / tls: - secretName: metaphor-tls hosts: - metaphor-development.your-company.io
Some Cool Automated Things to Note:
- The value specified in
spec.rules.hostwill automatically create a route53 CNAME that is bound to the Ingress elastic load balancer.
cert-manager.io/cluster-issuerannotation will prompt
cert-managerto automatically create a certificate for your application and will store that cert in the
- NGINX will automatically route traffic to the Metaphors applications service based on the path-based/host-based routing specified in
Environment Configs and Secrets
The Metaphors applications also include a working example of how to leverage a multi-environment secrets management
paradigm powered by Vault and
There is also a ConfigMap implementation to demonstrate how to leverage non-sensitive configuration values.
The Metaphors applications are set up to provide cloud and container observability and monitoring best practices with Datadog. It demonstrates using Datadog for Metaphors application logs, container statistics, application metrics, application performance monitoring, dashboard, and alerting.
The Metaphors applications leverages hashicorp Vault for secrets management. Vault runs in the
and metaphor runs in
production, so it serves as an example for secrets management. To read more see our