Containers 101

Video Transcript

Welcome to Containers 101 on Cycle. We’ll cover creating an image source, deploying a container, networking, and environment services. To start, we grab some images. Using the dashboard under images, you can import sources from Docker Hub, a Docker registry, a Git repo, or a URL tarball. Today, we’re working with WordPress. We’ll fetch it from Docker Hub. For Docker registry, you use the registry URL to access the image directly.

Cycle supports authentication using a token for Docker Hub. For private images, generate a token in settings. Public images like WordPress don’t need authentication. Now, we need MySQL. We’ll import MySQL 5.7 from the available images.

We’ll create a new environment for WordPress deployment on our production cluster using default settings with IPv6. If you need an IPv4 address, you must select it during the environment setup, as it can't be changed later.

For WordPress, we'll make this stateful since it stores data. We’re using the default deployment strategy. The container name is "WordPress," and it auto-fills the hostname. Stateless containers don’t retain data between restarts, while stateful containers do. For deployment strategies, the manual option allows manual creation of instances.

To control where the container runs, you can add node tags to constrain deployment. The "No Tag Any" option allows deployment to servers with any of the listed tags.

We’ve set up everything and will now deploy. WordPress depends on MySQL, so we'll deploy MySQL first and call it "DB." By default, public network access is disabled for security, but you can enable it if needed. For databases, restrict access to the environment.

WordPress requires environment variables for the database. Enter these in the config runtime, and start the container. The initial start is slower due to image copying, but subsequent starts are faster. We're running on an IPv6 network with legacy mode disabled.

WordPress needs to communicate with the database via the discovery service, which facilitates container-to-container communication. We’ll start the discovery service first, then WordPress. We have a "start all containers" button, including service containers like the load balancer, if public network access is enabled.

With the discovery service online, we add environment variables for WordPress: DB host, user, password, and name. After starting WordPress, the load balancer gets an IP from GCP, and we set up DNS for the container. Use Cycle’s guide for DNS setup if needed.

After setting up DNS and enabling TLS, the service is reachable and managed. To communicate between containers, the discovery service resolves internal environment-level DNS queries. Using the two-way console, you can access containers, even running commands like ping to verify connectivity.

Cycle dynamically adds name servers when running in high availability mode, ensuring seamless internal communication.

This concludes the deployment overview. Thanks for joining, and stay tuned for more updates.