webUI

Logging into SquareScale

To login using your GitHub account, simply click on the following link on the SquareScale homepage:

_images/webui_signin_with_github.png

Checking SquareScale account status with Travis CI

Every SquareScale account is automatically synchronized with the corresponding Travis CI account if available (both free and pro accounts). To know if everything is correctly connected, click on your name on the top right and click on “me”.

_images/webui_travis_status.png

Creating a project

To create a new SquareScale project a handful of steps, click on the following button on the homepage:

_images/webui_create_new_project.png
  • Then choose a name for your project:
_images/webui_project_name.png
  • Choose an infrastructure type (HA or development):
_images/webui_infra_type.png
  • Select a managed database server and its size (or no DBMS if you don’t need one):
_images/webui_dbms_select.png
  • Add the Slack URL for this project’s notifications if you have it:
_images/webui_slack_config.png
  • Finally click on the “create project” button to create it with all the above parameters:
_images/webui_create_project.png
  • A few minutes later, your platform is available:
_images/webui_platform_available.png

Deleting projects

To delete an existing SquareScale project…

Integrating Slack into a SquareScale project

It’s possible to send all notifications to a Slack channel, using a custom Slack hook. You can create a custom Slack hook at the following URL: https://<your_company>.slack.com/apps/manage/custom-integrations .

To add this URL, navigate to the Settings tab of the project and click on “update”:

_images/webui_slack_config_after.png

Here’s a sample SquareScale notification on a Slack channel:

_images/cli_add_slack.png

Setting up a service from a GitHub Repo

Our goal here is to add the GitHub repository available at https://github.com/sjourdan/hello to the SquareScale project named “yet-another-project”. Also, our project is simple and can be built only with the “internal” builder (a simple docker build).

The code from the repository, once built as a Docker image, will be available as a SquareScale service.

  • To add a service, from the “Overview” tab of the project, click on “Add service”:
_images/webui_platform_available.png
  • Select “GitHub” as a source, “Internal” as the builder and enter the project’s GitHub URL:
_images/webui_add_new_service_1.png

Note: Travis CI can very well be also selected, but it needs some dedicated configuration, out of focus for this quick documentation.

  • Click on “Add Service” and wait for the project’s Docker image to build and launch.

You’ll be presented with the service configuration tab immediately after, with a live dashboard of the build and deployment status:

_images/webui_service_config.png

The overview tab lists all the services running and their status:

_images/webui_all_services.png

Setting up a service from a Docker image

To create a service from an already existing Docker image is easy:

  • From the “Overview” tab of the project, click on “Add service”:
_images/webui_platform_available.png
  • Select “Docker” as a source and enter it’s name:tag (Docker Hub public image only)
_images/webui_add_docker_image.png
  • You can add image from a private Docker Hub repository.

You just need to check the option and fill in your Docker Hub credentials

_images/webui_service_config_private_docker_image.png
  • Click on “Add Service” and wait for the image to download and launch.

You’ll be presented with the service configuration tab immediately after, with a live dashboard of the deployment status:

_images/webui_service_config_docker_image.png

Listing running services on a project

To list available services, their status, and the number of instances for each of them, go to the “Overview” tab:

_images/webui_all_services.png

Accessing details about a service

Lots of details are available about a SquareScale service. To access them, from the “Overview” tab, click on the “settings” icon (the wheel);

_images/webui_all_services.png

Once in the service details tab, you can access the following information and configuration options:

  • number of service instances
_images/webui_service_instances.png
  • change the default run command
_images/webui_service_run_cmd.png
  • change the update command to be launched before run (like a database migration)
_images/webui_service_update_cmd.png
  • service requirements like memory limits
_images/webui_service_reqs.png
  • access/add/change dedicated environment variables
_images/webui_service_env_vars.png
  • find service restart webhook

This is useful when you want to force your service to restart.

_images/webui_service_trigger_webhook.png

Scaling up & down the number of instances of a service

If you want to scale up or down and change the number of instances of a given service (sjourdan/hello in this example), you can set it directly in the service tab:

_images/webui_service_instances_up.png

Validate and you’re done. See the result on the “Overview” tab:

_images/webui_services_overview.png

Setting a memory constraint on a service

It’s easy to mitigate memory leaks consequences or optimize memory usage of a service, using the memory constraint feature. Whether you’re interested in minimizing the memory usage of your service, or imposing a high memory reservation for an important service, you can use the following:

  • Go to the service setting tab
  • Change the memory requirement:
_images/webui_service_mem_reqs.png
  • Validate

If the memory requirement can’t be met, you’ll be notified.

Overriding the command or arguments of a service

To override the default container command or its arguments (wether the Dockerfile uses a CMD or an ENTRYPOINT):

  • Go to the service setting tab
  • Change the default run command:
_images/webui_service_run_cmd.png

Now the sjourdan/hello service will run with the --enable-hidden-feature=true argument until you remove it.

Force restarting a service manually

This feature is here to help you on the path to Continuous Deployment.

When you add a service from a GitHub repository, we listen to updates on the repository. Your service stays up-to-date by rebuilding and restarting each time a new commit is done on your master branch.

When using a private Docker image, we have no way to know when a new version of the image:tag is available.

This is where schedule webhook is useful: it allows you to trigger a restart of the service whenever you want, typicaly after you push a new version of your image:tag on your registry.

_images/webui_service_trigger_webhook.png

You could for example setup a webhook on your private Docker Hub repository using the schedule webhook URL of your service.