How to Deploy Your Code on Webscale
The Webscale deployment process is a modern CI/CD pipeline, with your code being managed by source control and then deployed using Docker containers. This removes the majority of downtime associated with deploying the code for a new application or website. In the past, it was necessary to set your Magento application to maintenance mode while the build processes were run, often resulting in downtimes of at least 1-2 hours. Using this modern CI/CD pipeline not only ensures little to no downtime, but also allows you to fix any problems with the site much more quickly.
Note:Since this deployment process is new, not all existing customer implementations are designed to use it. Customers who are on the legacy deployment method and would like to redeploy using the Docker-based deployment method outlined here should reach out to their Webscale account manager to discuss their options.
This deployment process uses Docker containers and the AWS ECR container registry to take all of the code compilation steps that are part of the build process and add them to a Docker deployment script, which uses the code from your source control to build an image. This Docker image build can be run on a staging server while the production site is still live. This allows your team to test and verify the new deployment without impacting your customers. Once you’ve verified that the site builds properly, you can deploy the same image to production quickly, while all of the site’s assets are simultaneously deployed, resulting in near-zero downtime. Since a new build can be done quickly with a Docker script, any problems with the production site can be quickly resolved by simply rolling back to an older Docker image stored in the container registry.
Note:Docker container images deployed on Webscale are deployed as
read-only, to help ensure the stability and integrity of the production environment. Any code changes or testing should be done using a Docker image on a staging environment. Once the image has passed your testing, you can then deploy it to production, replacing the current production environment. Since this deployment process uses containers, there is little to no downtime as part of the process because the build has already been verified.
WarningThese steps are a general outline that applies in most situations. Your situation may differ depending upon the configuration of your application and its implementation. If so, more specific details will be provided during the onboarding process.
- Webscale will authorize OAuth access to the AWS account for your Git repository (either GitHub, Bitbucket or GitLab).
- Upon a push into your Git repo,
codebuildwill build a container image with your code.
- This process uses the Dockerfile to create the container image (a default Dockerfile template can be provided, if required). Note: Future images will have a “commit ID” tag by default - this comes from the Git repository.
- Once the container is built using the Dockerfile, the container is pushed to AWS ECR.
- ECR runs a vulnerability scan on the container.
During onboarding, Webscale will grant you access to a deployment system via SSH that is specific to the environment to which you want to deploy. Run these commands in that environment (i.e., production or staging). The following procedure provides instructions for deployment for a staging environment. In the example, the commit id is “abc123” and Git branch name is “m2stage.”
Note:You may need to upgrade your environment if you don’t see any Git branch tags [branch-branchname]. Please let us know if this is the case.
To deploy in a staging environment
SSH into the deployment system and run the following commands:
- Find the container that you want to deploy in the list. The images are sorted from oldest to newest with the oldest image at the top, so that the latest built image is at the bottom.
If you know your commit ID, run
tag-by-commit [commit id] stagingto tag the image as ready to deploy.
If your environment supports tagging by branch, run
tag-by-branch [branch name] staging
Run the deployment script:
$ list-images "sha256:250eab59befa478121d87a06adf2745b32ceb97166d7d1fc99800785feada144": [ "branch-m2dev", "commit-xyzasdf", "staging" ] "sha256:035dbb834079c8103c4193ce4c6ac1609d1c2f7fdf9556635770f83dbb4e5e30": [ "branch-m2stage", "commit-abc123", ] $ tag-by-commit abc123 staging OR $ tag-by-branch m2stage staging 2021-08-08T08:08:08 [*docker tag*] Assigning tag staging to image [commit(abc123) digest(sha256:abcxyz456)]. $ run-deploy-and-cleanup Waiting for servers to verify...complete New cluster example-env-b is live. Waiting 30 seconds before cleaning up old cluster example-env-a Deleting old servers Done
- Docker container: A standard unit of software that packages code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
- Container image: A lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
- Dockerfile: A text document that contains all the commands a user could call on the command line to assemble an image.
- Container registry: A collection of repositories made to store container images.
- OAuth: An open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
- Git: A distributed version-control system for tracking changes in any set of files, originally designed for coordinating work among programmers cooperating on source code during software development.
- The Webscale Control Panel Dashboard
- How to Contact Support
- Frequently Asked Questions
- Dockerfile Reference
Have questions not answered here? Please Contact Support to get more help.
Was this page helpful?
Glad to hear it! Have any more feedback? Please share it here.
Sorry to hear that. Have any more feedback? Please share it here.