Deploy a service on ZopCloud

Outcome

By the end of this lesson, you will be able to deploy a running service on ZopCloud, name the four objects a deploy needs, and identify which steps a person must do because no assistant can.

1. Concept

Part 1 of this capstone put a resource in your own cloud account under ZopNight. Part 2 is about something else: shipping. You deploy a service on ZopCloud, then operate it through an assistant.

Keep the two parts apart in your head. ZopCloud runs your service on a shared pool of VMs that ZopDev operates, not in your cloud account. ZopNight does not discover ZopCloud services, so nothing you deploy here appears in ZopNight’s resource list or goes on a ZopNight schedule.

A ZopCloud deploy needs four objects, in this order:

PROJECT       the container. One per product or team.
  ENVIRONMENT   dev, staging, prod. Lives inside a project.
    SERVICE       your app. Lives inside an environment.
      DEPLOY        one shipped version of that service.

Miss one and the next refuses. You cannot deploy a service into nothing, and you cannot create an environment that belongs to no project.

What a person has to do, and why

Three steps in this module have no assistant equivalent at any level of access:

CREATE AN ACCOUNT        signing up is a person with an email
CONNECT A CLOUD          hands over credentials (Part 1, for ZopNight;
                         the ZopCloud deploy does not need it)
GRANT WRITE ACCESS       an org setting, ticked by an admin

That is not a gap waiting to be filled. Each one either establishes who you are or hands over the keys, and both stay with a human on purpose. Everything after them is fair game, which is the point of the next lesson.

What you are deploying

Any container image that listens on a port will do. The rest of this part assumes something small and boring: a hello-world HTTP service you do not mind restarting, rolling back and redeploying.

2. Demo

PROJECT       university-capstone
  ENVIRONMENT   dev
    SERVICE       hello-api
      image       ghcr.io/<you>/hello-api:v1
      port        8080
      replicas    1
      expose      on, so it gets a URL

RESULT
  https://hello-api-<id>.<your-zopcloud-domain>   200 OK

The URL is the object that matters for the rest of this part. Keep it.

3. Hands-on (6 min)

1. Sign in to ZopCloud. If you do not have an account, create one first.
2. Create a project. Call it university-capstone.
3. Create an environment inside it. Call it dev.
4. Create a service in that environment:
     - point it at a container image you can pull
     - set the port your app listens on
     - leave replicas at 1
     - turn on expose, so the service gets a public hostname
5. Ship the first deploy and wait for it to go green.
6. Open the service URL in a browser. It should answer.

IF IT DOES NOT GO GREEN
  Read the build output first, then the running replica's log.
  A deploy that never starts is almost always the image or the port.

What you need first.

BEFORE  A ZopCloud account. A container image you can pull, and the port it
        listens on. No cloud account is needed for this part.
ASK     nothing yet. Do this one by hand.
CHECK   the URL answers before you move on. L4 repeats the whole thing in one
        sentence, and it is only a fair comparison if you have done it the
        long way once.

4. Knowledge check

Q1

You create a service in an environment that does not exist yet. What happens?

A. The environment is created implicitly with default settings
B. The service is created and stays unassigned until an environment appears
C. The call refuses, because a service lives inside an environment and the parent must exist first
D. The service deploys into the project’s default environment

Q2

Which of these can an assistant do for you today?

A. Create your ZopCloud account
B. Connect your AWS account
C. Create the project, environment and service, and ship the deploy
D. Turn on write access for the organisation

Q3

Your deploy goes green but the URL returns nothing. The most likely cause:

A. The cloud account lost its credentials
B. The service is listening on a different port than the one you declared
C. Discovery has not run yet
D. The project was created in the wrong region

5. Apply

Keep three things from this lesson, because the certification requirement checks for the deploy and L4 builds on it:

KEEP
  the service URL
  the project and environment names
  the organisation this all lives in

If you are doing this on a work account, use a sandbox project rather than an existing product’s. Everything in this module is reversible, but the point is to practise without an audience.

Related lessons

• L4: The same deploy, asked in one sentence
• T1.M1.1.L1: Vault credentials: the model
• T1.M1.2.L1: What gets discovered and how

Glossary terms touched

Deployment · Service account · MCP