DOCSEARCHbyAlgolia
Submit Docs

Silta Documentation

website·Indexed 29 days ago

https://wunderio.github.io/silta/

Documentation for Silta, a tool for managing deployments across various environments. It includes guides on silta.yml configuration, CircleCI integration, Kubernetes cluster connections, SSL certificate management, and guidelines for Drupal and frontend projects.

Tokens
12.6K
Snippets
72
Records
98
Agent score
75%

What's inside Silta

  1. Manage project code and infrastructure in GitHub

    All project code and infrastructure configurations are versioned in GitHub within the organization. While any Docker-compatible application is supported, the organization provides default templates for Drupal projects, customized services (formerly frontend projects), and static pages.

  5. Using Silta outside of Wunder

    Silta's code is open and can be used outside of the Wunder ecosystem, although this specific use case is not currently a primary focus of development.

  6. Customize the frontend build command in Silta CircleCI

    By default, the npm-install-build step runs npm run build. To use a different build command, specify it using the build-command parameter.
    - npm-install-build:
    build-command: "compass compile --production"

  7. Configure GitHub branch protection and CI access for Silta

    Before going live with a Silta project, ensure that deletion protection is enabled for both the master and production branches. Additionally, verify that all necessary personnel are added to the group with access to the production CircleCI context to ensure deployment pipelines can execute.

  8. Build and test custom Docker images locally

    To test a customized Dockerfile locally, you must build the image, tag it, run it with an entrypoint (such as sh), and then remove the test image. Ensure you have Docker version 20.10 or higher to support Alpine 3.14+ images.
    # Build image and tag it with `shell_test_build` tag
docker build -t shell_test_build -f silta/shell.Dockerfile .

# Run tagged image and exec into it with `sh` shell 
docker run -it --entrypoint sh shell_test_build

# Remove test image
docker image rm shell_test_build

  9. Specify a custom path for npm install in Silta CircleCI

    If your package.json is not located in the Drupal root folder (e.g., it is inside a theme folder), you can specify the path to the frontend folder using the path parameter in the npm-install-build command. This path must be relative to the Drupal root.
    - npm-install-build:
    path: web/themes/custom/mytheme

  10. Forward Host header in CloudFront for Drupal URL generation

    To ensure Drupal generates URLs using the end-user's domain and scheme rather than the internal Silta domain (e.g., https://production.my-project.dev.[clusterDomain]), you must configure CloudFront to forward the Host header to the origin. This is achieved by applying a managed or custom cache policy under the "Cache behaviors" tab in the CloudFront console.

  11. Add custom Helm subcharts to a deployment

    You can extend the deployment by adding custom subcharts via an extension file.

    1. Create silta/extra_charts.yml listing the subcharts. Use the condition key if the subchart should only be installed when a specific value is set in silta.yml.
    2. Update the drupal-deploy job in CircleCI to include the extension_file.
    3. Configure the subchart variables in silta.yml using the subchart's name as the top-level key.
    # silta/extra_charts.yml
charts:
- name: redis
  version: 16.8.x
  repository: https://charts.bitnami.com/bitnami
  condition: redis.enabled
    # .circleci/config.yml
- silta/drupal-deploy:
    source_chart: wunderio/drupal
    extension_file: silta/extra_charts.yml
    # silta.yml
redis:
  enabled: true
  auth:
    password: test

  12. Optimize Silta production resources for high availability

    To ensure stability and high availability in production, follow these resource guidelines:

    1. Assign dedicated resources to each service (e.g., PHP/Javascript, MariaDB, Elasticsearch, Memcached).
    2. Enable autoscaling for relevant services with a minimum of two replicas.
    3. Perform a basic load test to verify that the autoscaling mechanism triggers correctly under load.