Cloning and Overwriting Containers

With container cloning and overwriting, you never need to edit in production again. Instead, you can create and move exact copies of existing containers whenever you need to. This is the safest way to create test environments, to push changes live, and also to migrate containers between servers.

These features are only available on managed containers.

Cloning and overwriting are easy to do, but there are a few things to understand before jumping in.

These Processes Use Exact Copies of Files and Databases

When you clone a container or overwrite data from one container to another, an exact copy of the source container or data is created. No other files are created, and nothing is edited or removed. No information is updated in your database. Hardcoded passwords or website URLs, for example, are directly copied into cloned or overwritten config files or databases. To make sure the new container operates like it should, you might need to:

Manually update data that needs to change between environments. Use Environment Variables to make switching environments even more automatic, and to improve security by not storing secret data like passwords directly in files or code repositories.

Choosing Between Cloning and Overwriting

Depending on the job you’re doing, either cloning or overwriting will be the best fit. Before you start, it’s important to know exactly what each process does.

Cloning: What It Does and When to Use It

When you clone a container, you create a new container with an exact copy of an existing container’s application, config and crontabs folders.

You can also clone databases. As with containers, the new database contains an exact, unedited copy of the source database. You also have the option to also clone database users and their permissions.

Cloning is very useful for:

• Setting up staging environments. By cloning a container you can give yourself a copy of, say, a WordPress website to work on when upgrading PHP, adding plug-ins, or making config changes. Any unexpected issues will only affect the clone, leaving a stable experience for visitors to your live site.
• Migrating containers between servers. If you have multiple servers on the Webslice Containers platform, container cloning can work from one server to another. Migrate entire containers with no manual shifting of files or copying and pasting of data.

Overwriting: What It Does and When to Use It

When you overwrite an existing container, its folders are replaced with copies of folders from another container. You control whether all folders are overwritten; or only your choice(s) of the application, config and crontabs folders. After overwriting, the two containers’ folders are exact copies of each other.

Before it is overwritten, the destination container is stopped and a backup is taken in case you need to restore it.

You can also overwrite a database with content from another.

Overwriting is useful for:

• Applying changes from staging to production. When you have separate containers for staging and production versions of your website or application, overwriting from staging is the final step to putting changes live.
• Synchronising data. Whenever you need files or content to be consistent between containers or databases, overwriting is a sure-fire way to keep things in sync.

Six Things to Know Before You Clone or Overwrite a Container

Usually in this documentation we get right into the “how to” steps, but there are some important things to know before you start cloning or overwriting containers.

• You need enough free storage space on your server for a copy of the container even if you are cloning or overwriting to a separate server. This space is needed for a temporary copy of the container.
• No files or databases will be changed in any way, so you might need to make some configuration changes to your cloned or overwritten container. (Yes, we’ve already mentioned this above, but it’s important!)
• Destination containers will be stopped while they are overwritten.
• Any data added or changed on a production container after the cloning process starts will not be included in the clone. If you are creating a staging environment, stopping the container first will ensure that it’s in the exact same state as production.
• All cron jobs are cloned, but some cron jobs probably shouldn’t run twice every time. This is why you can clone a container to a shutdown state. This is useful if your cron jobs send email, change database credentials, or hook into services like billing.
• Take care with production databases and user credentials. If you are cloning a container where these things will also be on the destination server, we recommend that you shut down the container before you start cloning. Then you can modify the database connection details and avoid a situation where, for example, the cloned container uses the production database.

How to Clone a Container

You can clone a container from the main Containers screen in the Webslice Console. Click the icon alongside the container’s name to get started. It’s a self-explanatory process, so long as you have read up on how it works and what you need to know first (all of which is above).

When creating a clone, your options will include the new container’s server, and whether it is created in a shut down state. You can also choose whether to clone databases.

How to Overwrite a Container

Like cloning, this is an easy process to take yourself through. It’s important that you’ve read the top sections of this doc to learn how it works and what you need to know.

In the main Containers screen, find the container that you want to duplicate (i.e. the source of the overwrite, not the destination). Click the icon alongside the container’s name to get started.

Rather than creating a new destination container, overwriting asks you to select an existing container. You can fully overwrite that container, or choose to leave its application, config, and/or crontabs folders unchanged. Overwriting the database is also optional.

Remember to keep the destination container shut down if you don’t want it to duplicate jobs like emailing customers, or if you need to change its database connection away from production.