4. Several ways of running your application¶

4.1. Prerequisites¶

We will assume that you have either:

A web application, accessible through http.
You want to deploy an instance of sc_pack on a separate server (edge server), to serve your application.

4.2. 1. Prepare for the process¶

Have on hand the information that is needed about the application to continue, for example, the estimation of the web traffic to know the capacity of the server, your ssl certificates, the routes of atypical URLs, etc.

4.3. 2. Install sc_pack in the edge server¶

There are basically three steps to setup and start using ShimmerCat Accelerator, plus one more to serve a website with ShimmerCat.

Create an authentication token that will work for at least a complete week.
Setup your edge servers with sc_pack.
Create deployments sites and domains.
Serve a website with ShimmerCat.

Details of step 1:

To use our accelerator you first need to create an authentication token.

Details of step 2-4:

The simplest, and recommended, way to complete steps 2 through 4 is to use our Ansible recipe created for that purpose.

This recipe will create and place in its respective locations the necessary configuration files (sc_pack.conf.yaml, devlove.yaml) and install the sc_pack. It will be responsible for installing and configuring the haproxy load balancer. Finally ShimmerCat and haproxy will be demonized.

4.4. 3. About devlove and haproxy config¶

Basically the devlove file must contain the following:

---
shimmercat-devlove:
  domains:
    elec www.example.com:
      root-dir:
        use-consultant: default
      views-dir: views-dir-www.example.com
      consultants:
        default:
          connect-to: "127.0.0.1:4430"
          application-protocol: http
          encryption-level: plain
      bot-protection-enabled: false
      change-url:
        - /.well-known//+/ -> <*>
        - /.well-known//+ -> <*>
        - //+</\.(js|css|jpg|png|gif|bmp|txt|svg|woff2|woff|ttf|json)/> -> <*>
        - / -> /target/+common/
        - //+/ -> /target/+common/slash/<+>
        - //+ -> /target/+common/no-slash/<+>/

And the haproxy configuration file

global
    log /dev/log     local0
    log /dev/log     local1 notice
    user shimmercat
    group shimmercat

listen stats
    bind :9000
    mode http
    stats enable
    stats realm Haproxy\ Statistics
    stats uri /haproxy_stats
    stats auth shimmercat:4.15.0-32-generic

frontend http_to_https_redirects
    bind *:80
    timeout client 20s
    mode http

    # ShimmerCat can do HTTP to HTTPS redirects, and so can Haproxy
    redirect scheme https code 301

frontend https
    bind *:443
    timeout client 3m
    option tcplog
    log /dev/log local0

    # ShimmerCat will do TLS termination, and fingerprinting, thus is
    # important to keep the proxy mode as TCP.
    mode tcp

    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    default_backend shimmercat_deployments

backend shimmercat_deployments
    # HTTPS will be terminated by ShimmerCat, this enumerates the
    # two ShimmerCat instances running in this very edge server
    timeout server 3m
    timeout connect 5s
    balance leastconn
    server deployment_A 127.0.0.1:4030 check port 8030

frontend to_application
    bind *:4430
    timeout client 3m
    timeout server 3m
    timeout connect 5s

    mode http
    default_backend example_application_servers

backend example_application_servers
    mode http
    timeout server 10s
    timeout connect 10s
    timeout check 10s
    balance leastconn
    server server_001 www.example.com:443 check port www.example:443 ssl verify none

Notes:

The scheme that we have followed in this configuration is the following: Haproxy port 443 -> ShimmerCat 4030 -> Haproxy 4430 -> Origin server Haproxy captures the request through port 443 and asks ShimmerCat to process it by the 4030, then ShimmerCat calls haproxy by the port 4430 and this is responsible for calling the web application.

4.5. 4. A set of views¶

Create all the directories, and files we list below under the sc_pack’s install-dir + devlove.yaml’s views-dir directory. For instance, if your sc_pack installation directory is /srv/deployment_A and the devlove.yaml contains views-dir: views-dir, then the first view listed below should be at /srv/deployment_A/views-dir/target/+common/index.html.

views-dir/target/+common/index.html

<!--
shimmercat:
    change-url:
       - /target/+common/ -> /
    content-disposition: replace
-->

views-dir/target/+common/__index.html

<!--
shimmercat:
    change-url:
       - /target/+common//+/ -> /
    content-disposition: replace
-->

views-dir/target/+common/no-slash/__index.html

<!--
shimmercat:
  content-disposition: replace
  change-url:
     - /target/+common/no-slash//+/ -> /<+>
-->

views-dir/target/+common/slash/__index.html

<!--
shimmercat:
  content-disposition: replace
  change-url:
     - /target/+common/slash//+/ -> /<+>
-->

If you want to know more about the rules and views we wrote above, please read: URL handling and re-writes and Views and devlove.

4.6. 5. Check that everything is fine¶

Configure your local /etc/hosts or equivalent, adding <your_remote_host> <www.example.com>
Open your browser and check https://www.example.com
If the website does not appear in your browser, please login to your remote server and check-restart the services.

Normally, the sc_pack service will be called with the one in the folder where it was installed (variable install_dir), replacing ‘.’ with “_” followed by “.service”, with the prefix sc-. For example: if install_dir is /srv/deployment_A, the service will be called sc-deployment_A.service You can check the status of services:

$ systemctl status sc-deployment_A.service

To restart it, run in the terminal:

$ systemctl restart sc-deployment_A.service

And, for the haproxy

$ systemctl status sc-deployment_A.service

$ systemctl restart haproxy.service

You can also check the logs files, located in the folders of the deploy. For example, the shimmercat logs are located in /srv/deployment_A/shimmercat/data/logs/current