Table of Contents
Shortcuts

11. Using sc_pack

11.1. Siloed deployments under a single directory

A deployment is a set of programs and configuration data under a single directory. This way, it’s easier to keep programs and their configuration compatible with each other

Here is how that hierarchy looks like:

    <install_dir>
      -- sc_logs_agent            
            -- data
              -- logs
                  current
      -- shimmercat
           -- data
              -- logs
                current
      -- shimmercat-scratch-folder
         -- sni-certs
         -- r-cache
         tweaks.yaml
         cert.pem
      -- usher3
           -- data
              -- logs
                current
      -- redis
           -- data
                redis.conf
      -- celery
            -- data
              -- logs
                 current
      -- <views-dir>
      -- <www>

The parts between angle brackets are variable, and of special notice are www and views-dir, of which we will talk a little bit more later.

Closely related to “deployment” is the notion of “deployment group”. A deployment group is a set of mirror deployments. For example, if “www.mytestsite.com” uses several caching servers, the deployments on each should be part of the same deployment group.

11.2. Starting the accelerator at boot time

Each deployment has a hidden folder .sc_pack-rkt with some files, one of them is the systemd service definition of the deploy: sc-<install_dir>.service.

Do a symlink (as root) of <install_dir>/.sc_pack-rkt/sc-<install_dir>.service to /etc/systemd/system

$ sudo ln -s <install_dir>.sc_pack-rkt/sc-<install_dir>.service /etc/systemd/system

Reload the systemctl daemon:

$ sudo systemctl daemon-reload

Start the services:

$ sudo systemctl start sc-<install_dir>.service

Check the services statuses:

$ sudo systemctl status sc-<install_dir>.service

11.3. Miscellaneous utilities

11.3.1. Using sc_pack to start and stop the processes

sc_pack helps you by acting as a thin shim that issues the corresponding commands to supervisorctl:

$ sc_pack ctl -f configuration/file/path/sc_pack.conf.yaml \
start|restart|stop \
shimmercat|redis|sc_logs_agent|all

You can use any combination of them to apply any action to individual components, or to all of them at the same time.

For example you can restart ShimmerCat by typing: $ sc_pack ctl reload shimmercat

11.3.2. Automatic updates of sc_pack

sc_pack also contains functions to update itself:

  • Update the sc_pack version through the sc_pack command:

    $ sc_pack update -f configuration/file/path/sc_pack.conf.yaml

  • You can add a line to the crontab with the options the scripts require. We give you an example with a line ready to include on your crontab that runs the update everyday at 1:00am, you can play with it, and following the doc here http://www.adminschoice.com/crontab-quick-reference change the frequency the script runs. Just run it:

    $ sc_pack crontab -f configuration/file/path/sc_pack.conf.yaml

Copy the line, and add it on the crontab either doing crontab -e or editing the /etc/crontab file. There are other options like using systemd units type timer as explained here.

11.4. Edit mode

The sc_pack has an edit mode. It means that you can edit content on any sc_pack instance, and then later push those changes to the accelerator to have those changes synchronized. You can do that by typing: $ sc_pack begin_edit and once you finish editing: $ sc_pack push_all

For instance suppose you need to edit the devlove.yaml to test something on the deployment test, and once you see those changes work push them to the accelerator platform. Then you just need to ssh to where test is deployed and type:

$ sc_pack begin_edit

then change some content on the devlove.yaml, and once you know they work do:

$ sc_pack push_all

While you are on edit mode we ensure that none is written automatically to that sc_pack instance, to avoid collisions.

Have into account that a $ sc_pack push_all --sync_with_all_deployments will sync those changes for this domain on all the deployment sites this domain is deployed.

11.5. Enable a specific viewset

You can now list the viewsets, and enable one of them. It is useful because you can get back to a specific viewset version, as you do with a commit on git. For instance, suppose that you edited a view by hand, and you did a $ sc_pack push_all --sync_with_all_deployments and that this change brake the site on all the deployments. You could then do:

$ sc_pack list_viewsets <domain_name>

see which was the previous viewset for this domain, and activate it again by doing:

$ sc_pack viewset <viewset_id> <domain_name>

11.6. Clone

You can clone a domain for a specific deployment site. The views, devlove file, and the certificates for this domain will be pulled from our accelerator platform and will be written on the sc_pack from where you are executing this command. The clone won’t affect any other deployment site associated to that domain.

$ sc_pack clone <domain_name>

11.7. Version

You can show the sc_pack version that is installed by running:

$ sc_pack version

11.8. Known issues

  1. If you are using haproxy, as load balancer, and the site does not start to load

Possible solutions: Make sure you have LARSI enabled. To do this open <install_dir>/shimmercat-scratch-folder/tweaks.yaml file, and should be as follows:

    ```
    ...
    security:
      enableLARSI: true
    ...
    ```

After making these changes restart the service: $ sudo systemctl start sc-<install_dir>.service

  1. sc_pack certs run_staging/run_prod issue:

If you have problems when you try to generate the certificates like a domain could not be validated then you are probably facing a timeout issue we have seen while using that command.

Possible solutions:

- Go to the ShimmerCat's scratch-dir directory there you will find a file
 called `tweaks.yaml`, and increase the value of the parameter: `lazyClientsWait`.
 Restart the ShimmerCat and try again.

- If you use `haproxy` for load balancing increase the:
    * frontend `timeout client`,
    * backend `timeout server`, and `timeout connect`

    Restart the `haproxy` and try again.

- If None of it works please contact us at [ops@shimmercat.com](mailto:ops@shimmercat.com) or through our <a href="https://shimmercatab.freshdesk.com/support/home" target="_blank">ticket system</a>.