Skip to main content

Overview

The application resource in Astro platform represents the core resource that encompasses a range from simple web applications, any Kubernetes operator to complex distributed systems like Kafka and Zookeeper. Applications are instantiated as pods within Kubernetes. Key aspects of the application resource include:

  • Versatility: Represents a wide range of applications, from simple web applications to complex systems like Kafka and Zookeeper.

  • Manifest Representation: Application manifests can be defined using Helm charts or YAML files, which may reside in Git repositories or public repositories.

  • Stateless Abstraction: Provides abstraction for stateless web applications, allowing developers to represent them via container images.

    Stateless Application

    The platform manages the Kubernetes (K8s) manifests, upgrades, DNS, and certificates for this abstraction. It incorporates best practices for deploying applications, including automatic configuration of horizontal pod auto-scaling, zonal placement, affinity, and more. Developers can focus solely on their application, as the platform takes care of reliable and scalable deployment. For more information on availability, refer to the Tiers documentation.

    In a future release, the platform will also support source-to-image (s2i) conversion, eliminating the need for developers to manually create container images.

  • Kubernetes API Access: Allows direct interaction with Kubernetes machinery APIs using Helm or YAML files. This advanced feature is suitable for enterprise environments where applications are complex to deploy.

  • Future Enhancements: Will include abstractions for deploying stateful applications.

    Future

    This will make the API agnostic to the underlying Kubernetes manifests

  • Configurations:

    • profileName: allows for cluster selection, resource management, and integration with different KMS systems.

    • source: defines the method for obtaining the application manifests.

Application Manifests​

AstroPlatform supports multiple methods to represent and deploy applications on Kubernetes. These methods provide flexibility and cater to various use cases, from simple web applications to complex systems. Below are the primary methods for representing applications, including examples based on the provided structure.

Methods to Represent Applications​

Image​

Helm Chart​

Repository​

Yaml​

Deploying Applications​

To deploy an application using astroctl, you can use the app subcommand. Here is the usage information for the astroctl app subcommand:

astroctl app apply -f <filename>

This command will display the help information for deploying applications with Astroctl. You can find more details on how to use this subcommand and its available options in the CLI documenatation

Debug Application​

To validate an application using astroctl, you can use the app subcommand. Here is the usage information for the astroctl app subcommand:

astroctl app logs
astroctl app events
astroctl app status

You can find more details on how to use this subcommand and its available options in the CLI documenatation

Target Namespace​

The application resource manifest supports configuring the namespace for application deployment in the target Kubernetes cluster. This field is optional, and if not configured, the platform will create the namespace as needed. Controlling the namespace is necessary in scenarios involving network-related manifests, such as inter-pod communication and ingress services. However, it is important to use this feature cautiously, as it is often unnecessary.

Syncing Manifests​

The syncType parameter determines whether the application should be automatically synced or not. It accepts two values: "auto" and "disable". The default value is "auto". This parameter is only necessary if we want to temporarily disable the syncing feature for testing purposes in the live cluster.

The auto-sync feature is particularly useful for git-sync with source repositories (private helm charts) or YAML files. Whenever there is a change in the resource on the configured branch in the git repository, the changes will be automatically synced to the destination cluster. However, if we want to disable this capability for any reason, we can set the syncType parameter to "disable".

Did you change?

If you forget to re-enable after disabling, the changes will not be propagated.

Upgrade​

Upgrading an application within this platform depends on the source type used for deployment. For detailed instructions on how to perform upgrades for each source type, consult the specific sections dedicated to Helm charts, YAML files, and Docker images within the documentation. Remember, it's crucial to review the changes and test the upgraded application in a development or staging environment before applying them to a production system.

Delete​

You can delete an application in your organization. If you have been added to the organization, you will need to ask the organization's admin to delete it, or you must have an admin role to delete it.