IuriiO Notebook
  • Broken Code Notebook
  • Architecture and Design
    • Architectural Decision Records
    • Trade-off Analysis
    • Data Decomposition Drivers
    • Selecting a Database Type
    • Service Granularity
    • Consumer-driven Contracts
  • Cloud
    • AWS
      • Resources
      • Compute
        • EC2
        • Batch
        • ECS & ECR
        • Elastic Beanstalk
      • Storage & Data Management
        • S3
        • Storage Gateway
        • RDS
        • DynamoDB
        • ElastiCache
        • Redshift
        • EBS
        • EFS
        • FSx
        • Snowball
        • Athena
        • Encryption and Downtime
        • Untitled
      • Security & Compliance
        • IAM
        • Web Identity Federation
        • Organizations
        • Service Catalog
        • Tags and Resource Groups
        • STS
        • KMS
        • GuardDuty
        • Compliance
        • Marketplace Security Products
        • DDOS
        • Compliance Frameworks
      • High Availability
        • Global Infrastructure
        • Disaster recovery
        • Elastic Load Balancers
        • Untitled
      • Monitoring & Reporting
        • Cost Explorer
        • CloudWatch
        • Systems Manager
        • Config
        • CloudTrail
        • Cost control
        • Untitled
      • Networking
        • Networking 101
        • Route53
        • CloudFront
        • VPC
        • DirectConnect
        • WAF
        • Shield
        • Global Accelerator
      • Deployment & Provisioning
        • Untitled
        • Untitled
      • Automation & Optimization
        • CloudFormation
          • Links
          • Github resources
          • YAML 101
          • Videos
        • OpsWorks
        • Untitled
      • Application Services
        • SQS
        • SWF
        • SNS
        • Untitled
      • Serverless
        • Lambda
        • API Gateway
        • DynamoDB
        • SAM
        • Untitled
      • Well-Architected Framework
    • Azure
      • Tools
      • Organization & Management
      • Authentication & Authorization
      • Compute
      • Networking
      • Storage
      • Databases
      • Security
      • Privacy, Compliance & Trust
      • Cost Management
  • Containers & Services
    • Docker
      • Useful Links
      • Containers
      • Images
      • Dockerfile
      • System
      • Compose
      • Swarm
      • Docker & NodeJS
    • Kubernetes
      • Useful Links
      • Introduction
      • Getting started
      • Exposing containers
      • Kubernetes Management Techniques
        • Declarative YAML
      • Labels and Annotations
      • Storage in Kubernetes
      • Ingress Controller
      • CRD's and The Operator Pattern
      • Kubernetes Dashboard
      • Kubectl Namespaces and Context
  • Frontend
    • Resources
    • Design
      • Search experience
Powered by GitBook
On this page
  • docker swarm init
  • Swarm Stacks: Production grade compose
  • Swarm Secrets Storage
  • Option 1 - create from file
  • Option 2 - Create from STDIN

Was this helpful?

  1. Containers & Services
  2. Docker

Swarm

Docker container clusters

docker swarm init

  • Lots of PKI and security automation

    • Root signing certificate create for our Swarm

    • Certificate is issued for first Manager node

    • Join tokens are created

  • Raft database create to store root CA, configs and secrets

    • Encrypted by default on disk

    • No need for another key / value system to hold orchestration / secrets

    • Replicates logs amongst Managers via mutual TLS in "control plane"

docker swarm join-token manager

  • scaling up to multiple containers:

  • docker service update --replicas <#>

Swarm Stacks: Production grade compose

  • IN Docker 1.13 Docker adds a new layer of abstraction to Swarm called Stacks

  • Stacks accept Compose files as their declarative definition for services, networks and volumes.

  • We use 'docker stack deploy' rather than docker stack create

  • Stacks manages all those objects for us, including overlay network per stack. Adds stack name to start of their name.

  • New 'deploy:' key in Compose file, does not support 'build:'

  • Compose now ignores 'deploy:'; Swarm ignores 'build:'

  • docker-compose CLI is not needed on Swarm server

docker stack deploy -c my-stack.yml demoapp docker stack services demoapp

Swarm Secrets Storage

  • Easiest "secure" solution for storing secrets in Swarm

  • Supports generic strings or binary content up to 500Kb in size

  • Doesn't require apps to be rewritten

  • As of Docker 1.13 Swarm Raft DB is encrypted on disk

  • Only stored on disk on manager nodes

  • Default is Managers and Workers "control plane" is TLS + Mutual Auth

  • Secrets are first stored in Swarm then assigned to a Service

  • Only containers in assigned Services can see them

  • They look like files in container but are actually in-memory file system

  • /run/secrets/{secrets-name} or /run/secrets/{secrets-alias}

  • Local docker-compose can use file-based secrets, but not secure

Option 1 - create from file

docker secret create psql_user psql_user.txt

Option 2 - Create from STDIN

echo "MyDbPassWORD" | docker secret create psql_user -

// Enable secret in the service

docker service create --name psql --secret psql_user --secret psql_pass -e POSTGRES_PASSWORD_FILE=/run/secrets/psql_pass -e POSTGRES_USER_FILE=/run/secrets/psql_user postgres

With compose 3.1 secrets are supported inside Compose files

secrets:
  my_first_secret:
    file: ./secret_data
  my_second_secret:
    external: true
    name: redis_secret

PreviousComposeNextDocker & NodeJS

Last updated 5 years ago

Was this helpful?