Please enable JavaScript.

Coggle requires JavaScript to display documents.

Cloud (Cloud Foundry (Components (self-service application execution…

- - - - routing target
        
        hosted application running on a Diego Cell
        
        Cloud Controller component
      - periodically queries the Diego Bulletin Board System (BBS) to determine which cells and containers each application currently runs on
  - - - Diego system distributes the hosted app load over all of the host VMs, and keeps it running and balanced through demand surges, outages, or other changes. Diego accomplishes this through an auction algorithm.
      - Before sending an app to a VM, the Cloud Controller stages it for delivery by combining stack, buildpack, and source code :question: into a droplet that the VM can unpack, compile, and run. For simple, standalone apps with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries.
  - - - OAuth2 access control
      - user database
        
        internal
        
        external
        
        LDAP
        
        SAML
  - - - internal component states
        
        MySql
        
        https://github.com/hashicorp/consul
        
        https://github.com/coreos/etcd
      - large binary files blobstore
        
        Application code packages
        
        Buildpacks
        
        Droplets
        
        provider
        
        internal server
        
        S3-compatible
      - GitHub
    - - channels
        
        NATS protocol to broadcast the latest routing tables to the routers.
        
        HTTP(S)
      - stores at
        
        Diego BBS
        
        Consul (longer-lived control data, such as component IP addresses and distributed locks)
  - - - CF system logs
      - app logs, metrics
      - The Loggregator system aggregates the component metrics and app logs into a structured, usable form, the Firehose
        
        triggering alerts
        
        analyse user behaviour
        
        apply nozzles
    - - how it manages apps
        
        BBS = Stores more frequently updated and disposable data such as cell and application status, unallocated work, and heartbeat messages. (Go MySql driver)
        
        CellRep = manages the lifecycle of those containers and the processes running in them, reports their status to the Diego BBS, and emits their logs and metrics to Loggregator.
        
        nsync
      - Diego Cell VM runs
        
        Garden container encapsulate Application instances, application tasks, and staging tasks
- - - - Docker for Windows 10
        
        uses Hyper-V
        
        more features than plain linux VM
        
        PowerShell native
      - Docker Toolbox for other versions
      - Docker Windows 2016
    - - LDAP
      - GUI
      - longer support lifecycle
    - - stable, once a quarter
      - edge = beta, valid for a month
      - YY.MM versioning
    - - direct/easyStart = runs on local metal
      - cloud IaaS, with cloud-specific features
  - - - all containers on a virtual network can talk to each other without being exposed via a port
      - each container is isolated and uses VPN bridge, only exposed via specific port
      - can use --net=host to use host IP
      - DNS Round Robing = poor man's load balancer, able to map multiple containter to respond to the same URL
        --net xox, --net-alias
    - - Data Volumes = special location outside of container filesystem
        :lock: need to be removed manually, outlives container.
        :warning: Windows stores this in linux VM, not filesystsm
      - Bind Mounts = maps host file to container file or dir, :smiley: dev-useful. Can't use in dockerfile, be be at container run -v //c/Users/...
      - practice: named volumes, used for persistent data
    - - docker-compose.yml descriptor
        
        version
        
        services
        
        volumes
        
        network
      - docker-compose command for docker automation for local dev
        
        -d
        
        .ro means read only
      - with docker command in Swarm (built-in orchestration), for prod
        
        not enabled out of the box, docker swarm init
        
        SwarmKit
        
        Stacks = Compose files for prod
        
        skips build commands, just deploys
        
        multi-service, multi-volume, multi-overlay-network, secrets
        
        runs on one swarm
        
        using secrets
        
        Secrets (built-in swarm-only)(with services)
        
        TLS certificates
        
        SSH keys
        
        usenames, passwords
        
        Raft DB encrypted storage, at manager disk, then assigned to services with a Stack file
        
        workers store secrects in memory only
        
        either a file (local development) or via command line
        
        pass the secret to a service and for convenience map the secret value to an environment variable
        
        Managers keeping replicated persistence database,encrypted comm, PKI certificat authority, commanding the working containers (gossip network)
        
        docker service replaces docker run in Swarm, to handle scaling
        
        vs Kubernetes :red_flag:
        
        jednodussi, Kubernetes je slozity na dobre nastaveni
        
        Hosting options
        
        play-with-docker.com 4-hour session limit
        
        locally docker-machine + VirtualBox (requires gigs of memory)
        
        Digital Ocean + docker install. Cheap
        
        Roll your own
        
        docker-machine can provision machines for Amazon, Azure, Google etc
        
        get.docker.com
        
        Overlay: swarm-wide bridge network, only for intra-swarm comm
        
        Routing Mesh (Scaling)
        
        spans all nodes in swarm
        
        uses IPVS from Linux Kernel
        
        load balances services across their Tasks
        
        stateless load balancing, using Virtual IP network
        
        OSI Layer 3 (TCP, not DNS) load balancer
        
        nginx or HAProxy or Docker EE solves shortcomings
        
        Lifecycle
      - new container-specific problems #
        
        how to automate container lifecycle?
        
        how to easily scale up/down?
        
        how to ensure recreation if container fails?
        
        hot to replace without downtime? (blue/green deploy = rolling update)
        
        track/control what is running where
        
        cross-node virtual networks
        
        ensure only trusted servers
        
        storing secrets and delivering them to the right container only
      - using secrets = not secure, but works for development (only file-based?)
  - - - Tags = pointers to specific commits
        
        latest (default, typically the most current version)
        
        can be pushed in a git fashion
      - can be private
    - - Image Id = SHA hash
      - repository (similar to maven gropupId+artifact) name + version
    - - FROM
      - ENV
      - RUN
      - forward logging to stdout stderr, container picks from there
      - EXPOSE 80 443
      - CMD = final command to run image
      - steps are hashed and don't need to be executed if it's already cached = very short build times :champagne:
        
        Keep things that change the least the top of your dockerfile
      - WORKDIR
      - COPY (from local to image)
      - Art of melting existing images with your Dockerfile. Iterative (--rm)
      - VOLUME
- - - - minimize
      - asynchronous REST endpoints (async JAX-RS)
      - asynchronous REST clients (HTTP is blocking, need wrapper on both sides)