Skip to content

Overview

The punch is not a monolithic platform that comes with an all-or-nothing logic. For the sake of clarity let us first identoify the several types of deployments.

  • Complete deployments : you have only servers, virtual or bare. In that case you deploy a complete punch that includes all the required components at play : kafka elasticsearch etc ..
  • Partial deployments : you already have some service up and running. Say Elasticsearch an Kafka. You then deploy only the punch additional modules and/or the punch embedded COTS you need. It does not differ from a complete deployment, you simply select only a subset of your components.
  • Container based deployments : if you have a container runtime environment such as kubernetes, you can deploy some of the punch applications directly using containers.

In the resst of this chapter we provide high level information for you to grasp the overall logic of a complete deployment.

How It Works

To deploy a punch you need a deployer laptop or server and the target (physical or virtual) servers where you want to deploy your platform. The starting situation is illustrated next.

image

The punchplatform-deployer.sh tool is a punchplatform software tool delivered as part of the installation package. All you have to provide is a description of your target platform. I.e. what component you want to deploy on what server. That description is up to you to define. In short you must provide a punchplatform-deployment.settings json file.

Once you have that deployment file, running the tool is easy and fully automated.

Configuration Management

It is important to understand the punch configuration logic, and how users interact with the platform.

There are two types of users : operators work using command line tools and have permissions to alter, start, stop or reload channels. These are the platform administrators.

In contrast
end-users interact with the platform with more restricted web consoles. End-users are allowed to edit only selected configuration items. For example edit an alerting rule. They cannot however alter the pipelines architectures, define or change the settings of critical components such as Kafka or Elasticsearch resources.

The punch deployer helps you to create the working environment for the operators. The working environment consists in a unix account, on a server equipped with the required binary packages and commands.
This is depicted next where the yellow server is the one where the operator environment will be deployed:

image

After that deployment step, there is no configuration defined yet. I.e. no tenant nor channels. The platform is up and ready, but empty. Somebody must therefore create the first configuration. A punch configuration is a per tenant configuration folder. You can import it on your own on the operator server, or use a punch deployer facility to do that for you at the end of your deployment.

One equipped with that configuration folder, the operator can start punch applications.

Supported Deployements

The punch can be deployed in several ways.

Bare/Vm Servers Deployment

Before you begin follow this OS specific setup

Then refer to the punchplatform-deployment.settings documentation.

Container Based deployment

Before you begin follow this Docker specific setup

Kubernetes Based package

Before you begin follow this Docker Kubernetes specific setup