Zero to Hero: Preparing a Custom Application

In today’s world, deploying applications is typically a headache. You have multiple CI/CD platforms, different ways to build containerized applications, and multiple environments to manage. Instead of having to worry about that, developers just want to get their code out. Whether it’s a new feature, a hotfix, or an entirely new application altogether, you want an easy-to-use method to make that happen.

In this blog post, you’ll learn one of the easiest methods for deploying apps in today’s world; Argonaut.

Creating A New App

In this section, you’ll learn how to create a new app on Argonaut along with all of the features and configurations available.

First, go to your environment and click on the environment name

Click the blue New App + button

You’ll see two options available:

• From Git: This option allows you to deploy a new app from source control via a Dockerfile
• From Library: This option is a list of pre-built apps that you can choose from.

Choose the From Git option.

When you get to the new application page, there are several configurations to choose from. You can configure anything from the app itself to the networking for the app to health checks. Let’s go over each configuration.

The App

The first option you have is the service type. The service type indicates what type of application is being deployed. For example, stateless and stateful.

Next, you have the service name, which is the name of the application.

After the service name, you can choose what Git organization you want to pull the app from, the repository name, and the branch. You can also enable branch previews.

Before clicking the 'More’ option, you can choose the Dockerfile path for your app. This section will build the code via the Dockerfile.

Clicking the ‘More’ option, you can add the working directory for your app, the service configuration, and the container registry for your Docker image.

Network Services

Under Network Services is where you’ll set up the network configuration for your application. The hostname if you’re setting up DNS along with the container port and the network protocol that’s needed for your app (HTTP, HTTPs, etc.).

Resource Options

There are two sections for resources:

• Resource Requests & Limits
• Horizontal Autoscaling

This is where you can set up the memory/CPU resources for your application, along with enabling autoscaling for your containerized apps. In this section, you’ll be thinking about the performance needs of a containerized application.

App Health Checks, Storage, and Secrets

In this final configuration stage, you’ll see that Argonaut enables you to have app health checks, persistent storage options, and store secrets in your app environment.

1. Health Check is via the Kubernetes environment. In Kubernetes, the health of an application is typically checked from /tmp/health inside of a Pod.
2. Persistent Storage is needed if an application isn’t stateless. As with pod containers, Pods are ephemeral, so no data should be stored on the pod itself. You should have persistent storage outside of the pod.
3. Secrets can be used to store Kubernetes’ secrets. Secrets can be anything from passwords and API keys to usernames if you feel compelled to not show them in plain text.

Update: Secrets can now be added directly by using your .env file. Refer to our April Release Note

Deploying a New App

Now that you understand what configuration options are available when getting an application ready, it’s time to deploy it! In this section, you’ll learn about the three different ways to configure an application.

The three options that are available are:

• Raise A Pull Request
• Generate Configurations
• Commit to Repo

Two essential components are created for all three options.

The first is the .arg directory, which is the Argonaut configuration. The configuration consists of a YAML configuration that contains everything needed by Argonaut to deploy and manage your application (application configs, Argonaut environment configs, storage, etc.). It lives inside of the Git repository.

The second is the CI/CD pipeline. When deploying an application, whether you’re using Gitlab or GitHub, a CI/CD pipeline gets created to actually deploy the application. The pipeline is auto-generated and is either a GitHub Actions workflow or a Gitlab pipeline.

Raise A Pull Request

The option to raise a pull request creates the .arg directory and CI/CD pipeline for you but doesn’t commit it right to the repository. Instead, it allows you and your team to review the configurations, confirm they’re what you want, and then merge the PR to your main or master branch.

Commit to Repo

If you want to skip the Pull Request (PR) process and move the Argonaut configurations and CI/CD pipeline directly to your main or master branch inside of the code repository, you can choose the Commit to Repo option. This option will bypass any PRs needed and push the configurations to the repository right away.

Committed Configurations

Generate Configurations

If you don’t want to create a PR or commit the code directly to the repository, you can simply generate configurations to confirm what they look like. That way, you can review them right from the portal and commit them to the repository or even just take a look at the configurations.

Wrapping Up

Managing the deployment of applications isn’t easy. There are several pieces that need to come together precisely including the code itself, the source control, the environment it’s going to, and the automation that’s in place to get the code shipped. With Argonaut, the idea is to make the deployment process as easy as possible. Instead of having to shuffle around several different UIs and automation tools just to get your containerized application running, you can do it all under one roof.

This article was written by Michael Levan for Argonaut.