Deploying behind a gateway server

About deployment gateways

If you want to deploy your application in a DMZ, you should prepare a bastion server which enables you to connect to your DMZ. You should define a Deployment Gateway in your Cloud 66 account and specify the information of the bastion server, then you will be able to deploy your application in the DMZ.

Required permissions

Team members must have Edit Deploy Gateways access rights to be able to use the deployment gateway.

How to deploy your application behind a gateway server

Gateway management is available through toolbelt .

First you need to define a gateway:

$ cx gateways add --name aws_bastion --address 1.1.1.1  --username ec2-user  --private-ip 2.2.2.2

In order to use this gateway for application deployment, you need to first specify it in the manifest:

production:
   	gateway:
   	    name: aws_bastion
   	    username: ec2-user

and then make it available before you start the deployment:

$ cx gateways open --name aws_bastion --key /tmp/gateway.pem

Now you can start deploying your application.

After the deployment is finished you can invalidate the gateway or leave it until the TTL is over.

$ cx gateways close --name aws_bastion

Kubernetes clusters behind a gateway server

On Deploy v2, you can build a Kubernetes cluster whose servers sit in a private subnet with no public IP address. Cloud 66 reaches your servers over SSH through your gateway, the same way it does for any other application. It reaches the Kubernetes API of your cluster (port 6443) through the same SSH connection, so you don't need to open or forward any other port on your gateway server.

Before you start

The gateway server needs a public IP address. We recommend an Elastic IP (or your cloud's equivalent), so the address survives if you ever replace the gateway server.
The SSH server on your gateway must allow TCP forwarding (AllowTcpForwarding), which is the default on most Linux distributions. Cloud 66 uses it to reach both SSH and the Kubernetes API on your cluster servers.
The private subnet needs outbound internet access, for example through a NAT gateway. Your servers download packages and pull your images while they are built and deployed.
Your gateway server's firewall (security group) must allow port 22 from our authorized IP addresses.
Set --private-ip on cx gateways add to your gateway server's private IP address, the address your cluster servers see its connections come from. Cloud 66 opens ports 22 and 6443 on your cluster servers to that address.

Create the cluster

Define your gateway and open it:

$ cx gateways add --name aws_bastion --address 1.1.1.1 --username ec2-user --private-ip 10.0.1.10
$ cx gateways open --name aws_bastion --key /tmp/gateway.pem

Start creating a new cluster and fill in the form as usual, choosing your VPC and your private subnet.
Instead of clicking Create Cluster, click Advanced deployment. This opens the manifest for your cluster. Add a gateway section at the top level, alongside cluster rather than inside it:

gateway:
  name: aws_bastion
  username: ec2-user

cluster:
  configuration:
    vpc_id: vpc-xxxxxxxx
    subnet_id: subnet-xxxxxxxx
  ...

Click Create cluster from manifest. Your servers are created without a public IP address, and Cloud 66 connects to them through your gateway from the first step of the build.

Keep your gateway open

Cloud 66 manages your cluster through your gateway, not only while you deploy. While the gateway is closed, deployments and changes to your servers stop with a message that the gateway is closed, and scheduled backups are skipped. Open the gateway and try again.

If you open the gateway without --ttl, it stays open until you close it.

Deploying applications to the cluster

Applications you deploy to the cluster use the cluster's gateway automatically. You don't need a gateway section in the application's manifest, but the gateway must be open while you deploy.

Using kubectl with your cluster

The kubeconfig file you download for a cluster behind a gateway points at https://127.0.0.1:6443. To use it, first open a tunnel to your master server through your gateway, and keep it running while you use kubectl. The easiest way is toolbelt:

$ cx tunnel -s "My Cluster" --server kubes_master --gateway-key /tmp/gateway.pem -l 6443 -r 6443

If you don't use toolbelt, open the tunnel with ssh instead. The download menu shows the exact command for your cluster, for example:

$ ssh -N -o ExitOnForwardFailure=yes -L 6443:10.0.2.20:6443 ec2-user@1.1.1.1

Here 10.0.2.20 is your master server's private IP address and 1.1.1.1 is your gateway's address. Use the key for your gateway's user, for example with -i /tmp/gateway.pem.

Replacing servers

If you replace the master server, it gets a new private IP address. Cloud 66 picks up the new address automatically. For kubectl, download your kubeconfig again and restart your tunnel. cx tunnel finds the new address by itself; with ssh, use the new address shown in the download menu.
If you replace the gateway server, make sure the new server meets the requirements in Before you start. Cloud 66 knows your gateway by both its public and private IP addresses. A new server usually gets a new private IP address even when you move the Elastic IP to it. If either address changes, update your gateway with cx gateways update rather than removing and adding it again:

$ cx gateways update --name aws_bastion --address 1.1.1.2 --private-ip 10.0.1.11

Limitations

The browser-based shell isn't available for servers behind a gateway. Use cx ssh --gateway-key instead (see below).

Adding servers behind an on-premises gateway

You can add registered servers to Cloud 66 via an on-premises gateway server as long as:

The registered servers are on the same network as the gateway
You are deploying a Rails application

To add a server behind your gateway:

SSH to the server and run the registered server registration script with the --header X-Fixed-IP:123.123.123.123 option - where X-Fixed-IP is set to the IP address that the gateway will use to access the server (usually the private IP address of the server).
Set up the gateway server and configure your application to use it via the manifest as specified above
Open the gateway and add the newly registered server to your application. Because the application is configured to use the gateway, it will go through the gateway and then direct requests to the IP address under X-Fixed-IP.

Accessing your servers behind the gateway server

If you want to connect to your servers behind the bastion server firstly you will need to have access to the bastion server's key, then you can use toolbelt to connect to your server:

$ cx ssh --gateway-key ~/.ssh/bastion_key  -s "My Awesome App" Lion