Technical Overview
Ahoy! stands on the shoulders of giants, namely Git, Helm, ArgoCD and of course Kubernetes. With these products combined, one can define deployments as code, commit them to a git repository, define how, where and when you’d like those deployments to be rolled out and they will also be kept in sync with your cluster, preventing any ad-hoc mishaps that creep in directly on the cluster from time to time.
This is where Ahoy! fits in; for all those that aren’t adept at writing yaml after yaml of Kubernetes objects to correctly define the deployment of the various elements of your applications or services, we’ve provided an easy-to-use user interface to describe your Clusters, Environments, Releases and Applications so that you can save yourself the time and effort of writing hundreds; if not thousands, of lines of yaml code and get your applications up and running in no time.
Granted, this will never give you all the flexibility that is offered by writing all of the deployment objects yourself, but with Ahoy! we are aiming for the 95% of applications and services out there that all need the same set of elements.
Design
With Ahoy!’s user interface, Release Managers will define their applications, which releases they are a part of, which environments they should be deployed to, that may span various clusters.
Ahoy! does this by taking these definitions and translating them into a Helm chart, then committing this helm chart to the configured Git repository, then creating the ArgoCD application that ties up the Helm chart in the Git repository to the Kubernetes cluster. ArgoCD then takes over and does the heavy lifting by making sure the Helm chart is in sync with what is deployed into the cluster.
Your defined release is now running in your environment.
Technical Overview
Ahoy! stands on the shoulders of giants, namely Git, Helm, ArgoCD and of course Kubernetes. With these products combined, one can define deployments as code, commit them to a git repository, define how, where and when you’d like those deployments to be rolled out and they will also be kept in sync with your cluster, preventing any ad-hoc mishaps that creep in directly on the cluster from time to time.
This is where Ahoy! fits in; for all those that aren’t adept at writing yaml after yaml of Kubernetes objects to correctly define the deployment of the various elements of your applications or services, we’ve provided an easy-to-use user interface to describe your Clusters, Environments, Releases and Applications so that you can save yourself the time and effort of writing hundreds; if not thousands, of lines of yaml code and get your applications up and running in no time.
Granted, this will never give you all the flexibility that is offered by writing all of the deployment objects yourself, but with Ahoy we are aiming for the 95% of applications and services out there that all need the same set of elements.
Design
With Ahoy!’s user interface, Release Managers will define their applications, which releases they are a part of, which environments they should be deployed to, that may span various clusters.
Ahoy! does this by taking these definitions and translating them into a Helm chart, then committing this helm chart to the configured Git repository, then creating the ArgoCD application that ties up the Helm chart in the Git repository to the Kubernetes cluster. ArgoCD then takes over and does the heavy lifting by making sure the Helm chart is in sync with what is deployed into the cluster.
Your defined release is now running in your environment.
Workflow
We all know, that’s not where the fun ends, there is an entire workflow that follows in order to promote releases to other environments, upgrade releases to newer versions, rollback defective releases etc.
Ahoy! helps with this, by applying the different configurations of the elements described above that essentially produces helm charts with slightly different values; each representing the specific configuration of a release for the destined environment, so that they are deployed to their respective environments with the correct setup.
Monitoring
Ahoy! incorporates an element of monitoring by reporting the status of all releases and their respective applications across environments and clusters. This allows a Release Manager at quick glance to identify any failed or problematic deployments and possibly remedy the failure.
Elements
Cluster
The Cluster refers to the Kubernetes cluster where one or more Environments may reside. It contains the necessary configuration for Ahoy! and ArgoCD to communicate to and perform administrative functions on.
Environment
The Environment refers to the conceptual environment; such as DEV/QA/PROD, that contains one or more Releases that should be deployed into the environment.
Environment configuration
An environment is important when it comes to configuration, as a release may; or most likely will, have configuration specific for the environment. Think of an application that connects to a QA database in the QA environment, and a PROD database in the PROD environment, these different databases will have for example different urls, usernames and passwords that would need to be defined for each environment. This is the Environment Configuration, where the release and the applications/services it contains do not change, only the environment configuration changes between the environments.
Environment configuration is set per application version, per release version, per environment.
Ahoy! assists in copying; if required, the environment configuration when promoting releases, upgrading releases or creating new application versions, so that you don’t need to start from scratch when defining the configuration for an application in a new environment.
Configuration includes:
– Replicas
– Route (Ingress)
– Environment Variables
– Resources
– Configuration Files
– Volumes
– Secrets
Note: environment configuration always overrides application configuration if they contain the same name, otherwise they are merged.
For example:
An environment value with name ENV_1; if set in environment configuration, will override ENV_1 in application version configuration, but if the application version configuration includes ENV_2 which is not set in environment configuration, the resulting environment variables in the container will contain ENV_1 and ENV_2.
Release
The release composes multiple applications and denotes the deployment.
Release version
A release version refers to the set of applications at specific versions.
For example:
– my-release – 1.0.0 can be made up of:
– service1 – 1.0.1
– service2 – 1.2.0
This allows for a snapshot of a set of applications and/or services that are compatible with each other.
A release version may be upgraded for a single or subset of application/service version upgrades.
Application
The Application refers to your application or service. Currently all applications refer to a Docker image, making it agnostic of programming language.
Application version: An application version is a single version of the application where you define the configuration of the application that spans all environments and clusters.
Configuration includes:
- Version
- Docker registry
- Containers
- Type; container or init container
- Name
- Image
- Command & Args
- Ports
- Health Checks
- Environment Variables
- Resources
- Configuration Files
- Volumes
- Secrets
Technical Overview
Ahoy! stands on the shoulders of giants, namely Git, Helm, ArgoCD and of course Kubernetes. With these products combined, one can define deployments as code, commit them to a git repository, define how, where and when you’d like those deployments to be rolled out and they will also be kept in sync with your cluster, preventing any ad-hoc mishaps that creep in directly on the cluster from time to time.
This is where Ahoy! fits in; for all those that aren’t adept at writing yaml after yaml of Kubernetes objects to correctly define the deployment of the various elements of your applications or services, we’ve provided an easy-to-use user interface to describe your Clusters, Environments, Releases and Applications so that you can save yourself the time and effort of writing hundreds; if not thousands, of lines of yaml code and get your applications up and running in no time.
Granted, this will never give you all the flexibility that is offered by writing all of the deployment objects yourself, but with Ahoy! we are aiming for the 95% of applications and services out there that all need the same set of elements.
Design
With Ahoy!’s user interface, Release Managers will define their applications, which releases they are a part of, which environments they should be deployed to, that may span various clusters.
Ahoy! does this by taking these definitions and translating them into a Helm chart, then committing this helm chart to the configured Git repository, then creating the ArgoCD application that ties up the Helm chart in the Git repository to the Kubernetes cluster. ArgoCD then takes over and does the heavy lifting by making sure the Helm chart is in sync with what is deployed into the cluster.
Your defined release is now running in your environment.
Workflow
We all know, that’s not where the fun ends, there is an entire workflow that follows in order to promote releases to other environments, upgrade releases to newer versions, rollback defective releases etc.
Ahoy! helps with this, by applying the different configurations of the elements described above that essentially produces helm charts with slightly different values; each representing the specific configuration of a release for the destined environment, so that they are deployed to their respective environments with the correct setup.
Monitoring
Ahoy! incorporates an element of monitoring by reporting the status of all releases and their respective applications across environments and clusters. This allows a Release Manager at quick glance to identify any failed or problematic deployments and possibly remedy the failure.
Elements
Cluster
The Cluster refers to the Kubernetes cluster where one or more Environments may reside. It contains the necessary configuration for Ahoy! and ArgoCD to communicate to and perform administrative functions on.
Environment
The Environment refers to the conceptual environment; such as DEV/QA/PROD, that contains one or more Releases that should be deployed into the environment.
Environment configuration
An environment is important when it comes to configuration, as a release may; or most likely will, have configuration specific for the environment. Think of an application that connects to a QA database in the QA environment, and a PROD database in the PROD environment, these different databases will have for example different urls, usernames and passwords that would need to be defined for each environment. This is the Environment Configuration, where the release and the applications/services it contains do not change, only the environment configuration changes between the environments.
Environment configuration is set per application version, per release version, per environment.
Ahoy! assists in copying; if required, the environment configuration when promoting releases, upgrading releases or creating new application versions, so that you don’t need to start from scratch when defining the configuration for an application in a new environment.
Configuration includes:
– Replicas
– Route (Ingress)
– Environment Variables
– Resources
– Configuration Files
– Volumes
– Secrets
Note: environment configuration always overrides application configuration if they contain the same name, otherwise they are merged.
For example:
An environment value with name ENV_1; if set in environment configuration, will override ENV_1 in application version configuration, but if the application version configuration includes ENV_2 which is not set in environment configuration, the resulting environment variables in the container will contain ENV_1 and ENV_2.
Release
The release composes multiple applications and denotes the deployment.
Release version
A release version refers to the set of applications at specific versions.
For example:
– my-release – 1.0.0 can be made up of:
– service1 – 1.0.1
– service2 – 1.2.0
This allows for a snapshot of a set of applications and/or services that are compatible with each other.
A release version may be upgraded for a single or subset of application/service version upgrades.
Application
The Application refers to your application or service. Currently all applications refer to a Docker image, making it agnostic of programming language.
Application version: An application version is a single version of the application where you define the configuration of the application that spans all environments and clusters.
Configuration includes:
- Version
- Docker registry
- Containers
- Type; container or init container
- Name
- Image
- Command & Args
- Ports
- Health Checks
- Environment Variables
- Resources
- Configuration Files
- Volumes
- Secrets