kalisio / kaabah Goto Github PK

S3 backend also supports state locking and consistency checking via Dynamo DB, which can be enabled by setting the dynamodb_table field to an existing DynamoDB table name.

On Scaleway, When attaching a disk to an instance, the instance must be stopped. Consequently, on each worker the /tmp directory is cleaned removing the scripts required to finalize the terraform process. Scripts should be stored elsewhere than in the /tmp directory

Instances and volumes may be created in different availability zones

https://vuepress.vuejs.org/

Should we unmount the volume using a provisionner ?

Secure the access to the server (SSH) and the services using a VPN

To facilitate the deployement strategie, it could be convenient to have some labels on the worker when setting up the infrastructure.
See: kalisio/crisis#26

We use the Dockre plugin for SSHFS (https://github.com/vieux/docker-volume-sshfs) but we are facing some issues when non root user. It is more convenient to use SSHFS directly.

This should allow to build locally a container and then to deploy it

on AWS the hostname is defined with the IP. It could be more convenient to have the tag name

When instancibg a new infrastructure, the manager's IP is new and traefik is not reachable because the DNS is probably not well configured. As Kaabah is using httpChallenge and uses traefik to generate a certificate for each frontends rules, it fails. A bypass is ti use the onDemand (https://docs.traefik.io/user-guide/examples/#ondemand-option-with-http-challenge) but it seems to be depricated. For now it works with this.

• provider.aws: version = "~> 1.21"
• provider.null: version = "~> 1.0"
• provider.scaleway: version = "~> 1.4"

See hashicorp/terraform#328

See: https://docs.docker.com/compose/compose-file/#resources

Currently, In C5, C5d, i3.metal, M5, M5d, R5, R5d, T3, and z1d instances, EBS volumes are exposed as NVMe block devices. The device names are /dev/nvme0n1, /dev/nvme1n1, and so on.

Ref: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html

See https://github.com/terraform-providers/terraform-provider-scaleway/issues

It could be worth to define the caServer from the Terraform configuration to bypass Let's Encrypt rate limits.

When tainting the services resource, the stack should be removed and the directory services should be cleaned.

• execute a command on a service. Must find the container
• execute a command on each worker

We are facing some security issues. See https://github.com/docker/docker-bench-security to list the recommendations

• Module Scaleway
• Module AWS

It does not allow to modify any dashboards. It should be Editor at least or Admin.
See: http://docs.grafana.org/administration/permissions/

• AWS
• Scaleway
• Clean the documentation (TIPS section)
• Cannot mount volumes on instance of type of t3
• Allow to define the mount point
• Update the documentation

Since we the workspaces are stored within a private repository, the check does not work anymore.
Does it make sense to do this check ? see #16

Not on entrypoint but for each frontends accessing to the services.

The command rely on the node id and we are providing the hostname

It seems to be an issue in Scaleway

We could take advantage of running a job via travis to compare the configurations against the states to validate the consitency of the infrastructures. Indeed when checking out the repository, if we execute the command terraform plan for each workspaces, we should have no changes.

Take benefit of this feature: https://docs.docker.com/compose/extends/#extending-services

Test:

• https://grafana.com/dashboards/609 👍 for containers not for node-exporter
• https://grafana.com/dashboards/6212 👎
• https://grafana.com/dashboards/405 👍
• https://grafana.com/dashboards/22
• https://grafana.com/dashboards/704

Instead of generating instances for each domain generate a Swarm master + a set of Swarm workers.

• Swarm infrastructure
• Traefik
• Portainer
• Prometheus
• S3 backend to store the states
• Support https/Let's encrypt
• Operational workflow

Interesting example: https://github.com/stefanprodan/scaleway-swarm-terraform.

By default, it must be derived from the infrastructure name without the environement flavor.
kapp-dev => kapp

• AWS
• Scaleway

It could be convenient to provide an existing IP to the manager when creating an infrastucture

Linked to hashicorp/terraform#14403

See https://github.com/vieux/docker-volume-sshfs
It appears to be a convenient way to share configuration files among containers. Comparing to docker config, it allows us to share a directory of files.

Since Kaabah is designed to monitor the infrastructure and the services deployed using Docker, blackbox-exporter is not useful in this context. We can remove it from the stack.