Skip to main content

Home/ Groups/ Larvata
Rss Feed
Sort By: Most Recent | Popular Filter: All | Bookmarks | Topics Simple Middle
張 旭

Docker for AWS persistent data volumes | Docker Documentation - 0 views

docs.docker.com/...persistent-data-volumes

aws docker system

shared by 張 旭 on 08 Oct 18 - No Cached
  • Cloudstor is a modern volume plugin built by Docker
  • Docker swarm mode tasks and regular Docker containers can use a volume created with Cloudstor to mount a persistent data volume.
  • Global shared Cloudstor volumes mounted by all tasks in a swarm service.
  • ...14 more annotations...
  • Workloads running in a Docker service that require access to low latency/high IOPs persistent storage, such as a database engine, can use a relocatable Cloudstor volume backed by EBS.
  • Each relocatable Cloudstor volume is backed by a single EBS volume.
  • If a swarm task using a relocatable Cloudstor volume gets rescheduled to another node within the same availability zone as the original node where the task was running, Cloudstor detaches the backing EBS volume from the original node and attaches it to the new target node automatically.
  • in a different availability zone,
  • Cloudstor transfers the contents of the backing EBS volume to the destination availability zone using a snapshot, and cleans up the EBS volume in the original availability zone.
  • Typically the snapshot-based transfer process across availability zones takes between 2 and 5 minutes unless the work load is write-heavy.
  • A swarm task is not started until the volume it mounts becomes available
  • Sharing/mounting the same Cloudstor volume backed by EBS among multiple tasks is not a supported scenario and leads to data loss.
  • a Cloudstor volume to share data between tasks, choose the appropriate EFS backed shared volume option.
  • When multiple swarm service tasks need to share data in a persistent storage volume, you can use a shared Cloudstor volume backed by EFS.
  • a volume and its contents can be mounted by multiple swarm service tasks without the risk of data loss
  • over NFS
  • the persistent data backed by EFS volumes is always available.
  • shared Cloudstor volumes only work in those AWS regions where EFS is supported.
張 旭

Use multi-stage builds | Docker Documentation - 0 views

docs.docker.com/...multistage-build

docker system

shared by 張 旭 on 29 Sep 18 - No Cached
  • Maintaining two Dockerfiles is not ideal.
  • This is failure-prone and hard to maintain. It’s easy to insert another command and forget to continue the line using the \ character
  • create a container from it to copy the artifact out
  • ...4 more annotations...
  • You only need the single Dockerfile. You don’t need a separate build script,
  • You don’t need to create any intermediate images and you don’t need to extract any artifacts to your local system at all.
  • Debugging a specific build stage
  • You can use the COPY --from instruction to copy from a separate image, either using the local image name, a tag available locally or on a Docker registry, or a tag ID.
張 旭

Best practices for writing Dockerfiles | Docker Documentation - 0 views

docs.docker.com/...dockerfile_best-practices

docker system

shared by 張 旭 on 28 Sep 18 - No Cached
  • building efficient images
  • Docker builds images automatically by reading the instructions from a Dockerfile -- a text file that contains all commands, in order, needed to build a given image.
  • A Docker image consists of read-only layers each of which represents a Dockerfile instruction.
  • ...47 more annotations...
  • The layers are stacked and each one is a delta of the changes from the previous layer
  • When you run an image and generate a container, you add a new writable layer (the “container layer”) on top of the underlying layers.
  • By “ephemeral,” we mean that the container can be stopped and destroyed, then rebuilt and replaced with an absolute minimum set up and configuration.
  • Inadvertently including files that are not necessary for building an image results in a larger build context and larger image size.
  • To exclude files not relevant to the build (without restructuring your source repository) use a .dockerignore file. This file supports exclusion patterns similar to .gitignore files.
  • minimize image layers by leveraging build cache.
  • if your build contains several layers, you can order them from the less frequently changed (to ensure the build cache is reusable) to the more frequently changed
  • avoid installing extra or unnecessary packages just because they might be “nice to have.”
  • Each container should have only one concern.
  • Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers
  • Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.
  • Use your best judgment to keep containers as clean and modular as possible.
  • do multi-stage builds and only copy the artifacts you need into the final image. This allows you to include tools and debug information in your intermediate build stages without increasing the size of the final image.
  • avoid duplication of packages and make the list much easier to update.
  • When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified.
  • the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated.
  • simply comparing the instruction in the Dockerfile with one of the child images is sufficient.
  • For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file.
  • If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
  • cache checking does not look at the files in the container to determine a cache match.
  • In that case just the command string itself is used to find a match.
    • 張 旭
      張 旭 on 28 Sep 18
       
      RUN apt-get 這樣的指令，直接比對指令內容的意思。
  • Whenever possible, use current official repositories as the basis for your images.
  • Using RUN apt-get update && apt-get install -y ensures your Dockerfile installs the latest package versions with no further coding or manual intervention.
  • cache busting
  • Docker executes these commands using the /bin/sh -c interpreter, which only evaluates the exit code of the last operation in the pipe to determine success.
  • set -o pipefail && to ensure that an unexpected error prevents the build from inadvertently succeeding.
  • The CMD instruction should be used to run the software contained by your image, along with any arguments.
  • CMD should almost always be used in the form of CMD [“executable”, “param1”, “param2”…]
  • CMD should rarely be used in the manner of CMD [“param”, “param”] in conjunction with ENTRYPOINT
  • The ENV instruction is also useful for providing required environment variables specific to services you wish to containerize,
  • Each ENV line creates a new intermediate layer, just like RUN commands
  • COPY is preferred
  • COPY only supports the basic copying of local files into the container
  • the best use for ADD is local tar file auto-extraction into the image, as in ADD rootfs.tar.xz /
  • If you have multiple Dockerfile steps that use different files from your context, COPY them individually, rather than all at once.
  • using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead
  • The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command (and then use CMD as the default flags).
  • the image name can double as a reference to the binary as shown in the command
  • The VOLUME instruction should be used to expose any database storage area, configuration storage, or files/folders created by your docker container.
  • use VOLUME for any mutable and/or user-serviceable parts of your image
  • If you absolutely need functionality similar to sudo, such as initializing the daemon as root but running it as non-root), consider using “gosu”.
  • always use absolute paths for your WORKDIR
  • An ONBUILD command executes after the current Dockerfile build completes.
  • Think of the ONBUILD command as an instruction the parent Dockerfile gives to the child Dockerfile
  • A Docker build executes ONBUILD commands before any command in a child Dockerfile.
  • Be careful when putting ADD or COPY in ONBUILD. The “onbuild” image fails catastrophically if the new build’s context is missing the resource being added.
張 旭

https://www.conventionalcommits.org/en/v1.0.0-beta.2/ - 0 views

www.conventionalcommits.org/...v1.0.0-beta.2

git commit programming code

shared by 張 旭 on 20 Sep 18 - No Cached
  • standardized commit message
  • fix patches a bug in your codebase
  • feat introduces a new feature to the codebase
  • ...11 more annotations...
  • a breaking API change
  • A breaking change can be part of commits of any type. e.g., a fix:, feat: & chore: types would all be valid, in addition to any other type.
  • We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug.
  • he type feat MUST be used when a commit adds a new feature to your application or library
  • followed by a colon and a space
  • The type fix MUST be used when a commit represents a bug fix for your application.
  • An optional scope MAY be provided after a type.
  • A description MUST immediately follow the type/scope prefix.
  • A footer MAY be provided one blank line after the body (or after the description if body is missing).
  • A breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon and a space
  • Types other than feat and fix MAY be used in your commit messages.
  • 張 旭 on 20 Sep 18
     
    "standardized commit message"
張 旭

Deploy services to a swarm | Docker Documentation - 0 views

docs.docker.com/...services

docker swarm system

shared by 張 旭 on 07 Sep 18 - No Cached
  • Swarm services use a declarative model, which means that you define the desired state of the service, and rely upon Docker to maintain this state.
  • To create a single-replica service with no extra configuration, you only need to supply the image name.
  • A service can be in a pending state if its image is unavailable
  • ...12 more annotations...
  • If your image is available on a private registry which requires login, use the --with-registry-auth flag
  • When you update a service, Docker stops its containers and restarts them with the new configuration.
  • When updating an existing service, the flag is --publish-add. There is also a --publish-rm flag to remove a port that was previously published.
  • To update the command an existing service runs, you can use the --args flag.
  • force the service to use a specific version of the image
  • If the manager can’t resolve the tag to a digest, each worker node is responsible for resolving the tag to a digest, and different nodes may use different versions of the image.
  • After you create a service, its image is never updated unless you explicitly run docker service update with the --image flag as described below.
  • When you run service update with the --image flag, the swarm manager queries Docker Hub or your private Docker registry for the digest the tag currently points to and updates the service tasks to use that digest.
  • You can publish a service task’s port directly on the swarm node where that service is running.
  • You can rely on the routing mesh. When you publish a service port, the swarm makes the service accessible at the target port on every node, regardless of whether there is a task for the service running on that node or not.
  • To publish a service’s ports externally to the swarm, use the --publish <PUBLISHED-PORT>:<SERVICE-PORT> flag.
  • published port on every swarm node
張 旭

How It Works - Let's Encrypt - Free SSL/TLS Certificates - 0 views

letsencrypt.org/how-it-works

https tls security server web

shared by 張 旭 on 19 Sep 18 - No Cached
  • The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention.
  • First, the agent proves to the CA that the web server controls a domain.
  • Then, the agent can request, renew, and revoke certificates for that domain.
  • ...4 more annotations...
  • The first time the agent software interacts with Let’s Encrypt, it generates a new key pair and proves to the Let’s Encrypt CA that the server controls one or more domains.
  • The Let’s Encrypt CA will look at the domain name being requested and issue one or more sets of challenges
  • different ways that the agent can prove control of the domain
  • Once the agent has an authorized key pair, requesting, renewing, and revoking certificates is simple—just send certificate management messages and sign them with the authorized key pair.
張 旭

Let's Encrypt & Docker - Træfik - 0 views

docs.traefik.io/...docker-and-lets-encrypt

traefik docker networking proxy

shared by 張 旭 on 19 Sep 18 - No Cached
  • automatically discover any services on the Docker host and let Træfik reconfigure itself automatically when containers get created (or shut down) so HTTP traffic can be routed accordingly.
  • use Træfik as a layer-7 load balancer with SSL termination for a set of micro-services used to run a web application.
  • Docker containers can only communicate with each other over TCP when they share at least one network.
  • ...15 more annotations...
  • Docker under the hood creates IPTable rules so containers can't reach other containers unless you'd want to
  • Træfik can listen to Docker events and reconfigure its own internal configuration when containers are created (or shut down).
  • Enable the Docker provider and listen for container events on the Docker unix socket we've mounted earlier.
  • Enable automatic request and configuration of SSL certificates using Let's Encrypt. These certificates will be stored in the acme.json file, which you can back-up yourself and store off-premises.
  • there isn't a single container that has any published ports to the host -- everything is routed through Docker networks.
  • Thanks to Docker labels, we can tell Træfik how to create its internal routing configuration.
  • container labels and service labels
  • With the traefik.enable label, we tell Træfik to include this container in its internal configuration.
  • tell Træfik to use the web network to route HTTP traffic to this container.
  • Service labels allow managing many routes for the same container.
  • When both container labels and service labels are defined, container labels are just used as default values for missing service labels but no frontend/backend are going to be defined only with these labels.
  • In the example, two service names are defined : basic and admin. They allow creating two frontends and two backends.
  • Always specify the correct port where the container expects HTTP traffic using traefik.port label.
  • all containers that are placed in the same network as Træfik will automatically be reachable from the outside world
  • With the traefik.frontend.auth.basic label, it's possible for Træfik to provide a HTTP basic-auth challenge for the endpoints you provide the label for.
張 旭

What are Docker : images? - Project Atomic - 0 views

www.projectatomic.io/...at-are-docker-none-none-images

docker system

shared by 張 旭 on 18 Sep 18 - No Cached
  • Now we understand what these <none>:<none> images stand for. They stand for intermediate images and can be seen using docker images -a
  • They don’t result into a disk space problem but it is definitely a screen real estate problem
  • dangling images
  • ...7 more annotations...
  • Another style of <none>:<none> images are the dangling images which can cause disk space problems.
  • In programming languages like Java or Golang a dangling block of memory is a block that is not referenced by any piece of code.
  • a dangling file system layer in Docker is something that is unused and is not being referenced by any images.
  • intermediate images
  • do docker images and see <none>:<none> images in the list, these are dangling images and needs to be pruned.
  • These dangling images are produced as a result of docker build or pull command.
  • docker rmi $(docker images -f "dangling=true" -q)
crazylion lee

GitHub - sindresorhus/ky: Tiny and elegant HTTP client based on the browser Fetch API - 0 views

github.com/ky

http json fetch api

shared by crazylion lee on 17 Sep 18 - No Cached
  • crazylion lee on 17 Sep 18
     
    "Tiny and elegant HTTP client based on the browser Fetch API"
張 旭

Networking with overlay networks | Docker Documentation - 0 views

docs.docker.com/...network-tutorial-overlay

docker networking

shared by 張 旭 on 14 Sep 18 - No Cached
  • The manager host will function as both a manager and a worker, which means it can both run service tasks and manage the swarm.
  • connected together using an overlay network called ingress
  • each of them now has an overlay network called ingress and a bridge network called docker_gwbridge
  • ...7 more annotations...
  • The docker_gwbridge connects the ingress network to the Docker host’s network interface so that traffic can flow to and from swarm managers and workers
  • recommended that you use separate overlay networks for each application or group of applications which will work together
  • You don’t need to create the overlay network on the other nodes, beacause it will be automatically created when one of those nodes starts running a service task which requires it.
  • The default publish mode of ingress, which is used when you do not specify a mode for the --publish flag, means that if you browse to port 80 on manager, worker-1, or worker-2, you will be connected to port 80 on one of the 5 service tasks, even if no tasks are currently running on the node you browse to.
  • Even though overlay networks are automatically created on swarm worker nodes as needed, they are not automatically removed.
  • The -dit flags mean to start the container detached (in the background), interactive (with the ability to type into it), and with a TTY (so you can see the input and output).
  • alpine containers running ash, which is Alpine’s default shell rather than bash
張 旭

Practical persistent cloud storage for Docker in AWS using RexRay - pt 4 - 0 views

blog.vizuri.com/ocker-in-aws-using-rexray-pt-4

docker volume disk aws storage

shared by 張 旭 on 14 Sep 18 - No Cached
  • Docker volumes can then be created and managed via the plugin, as requests are passed by Docker, and then orchestrated by the local server.
  • volumes are usually protected from deletion via a reference count.
  • Using the plugin means that the reference count is kept at the node level, so the plugin is only aware of the containers on a single node.
  • ...3 more annotations...
  • The S3FS plugin as of version 0.9.2 cannot delete an S3 bucket unless the bucket is empty, and has never been used (just created) as a Docker volume.
  • Starting with Docker 1.13 a new plugin system was introduced in which the plugin runs inside of a container.
  • Even though the plugin is a container image, you cannot start it using either docker image pull or docker container run; you need to use the docker plugin set of sub‑commands.
  • 張 旭 on 14 Sep 18
     
    "Docker volumes can then be created and managed via the plugin, as requests are passed by Docker, and then orchestrated by the local server."
張 旭

The Caddyfile Syntax - 0 views

caddyserver.com/caddyfile

caddy proxy HA

shared by 張 旭 on 12 Sep 18 - No Cached
  • A Caddyfile can be used to configure any Caddy server type: HTTP, DNS, etc.
  • The Caddyfile is plain Unicode text encoded with UTF-8.
  • lowercase and uppercase characters are different.
  • ...17 more annotations...
  • A token that starts with quotes " is read literally (including whitespace) until the next instance of quotes " that is not escaped.
  • Only quotes are escapable.
  • Blank, unquoted lines are allowed and ignored.
  • Tokens are then evaluated by the parser for structure.
  • A Caddyfile has no global scope.
  • A label is a string identifier, and a definition is a body (one or more lines) of tokens grouped together in a block
  • a Caddyfile with more than one entry must enclose each definition in curly braces { }.
  • The first line of a Caddyfile is always a label line.
  • If many labels are to head a block, the labels may be suffixed with a comma.
  • as long as the last label of the line has a comma if the next line is to continue the list of labels
  • Commas are not acceptable delimiters for arguments
  • Arguments are delimited solely by same-line whitespace
  • Subdirectives cannot open new blocks.
  • nested directive blocks are not supported
  • Any token (label, directive, argument, etc.) may contain or consist solely of an environment variable
  • Where an import line is, that line will be replaced with the contents of the imported file, unmodified.
  • define snippets to be reused later in your Caddyfile by defining a block with a single-token label surrounded by parentheses
張 旭

Caddyfile Tutorial - How to Configure Caddy - 0 views

caddyserver.com/...caddyfile

caddy proxy tutorial

shared by 張 旭 on 12 Sep 18 - No Cached
  • Directives are keywords that Caddy recognizes.
  • Directives might have one or more arguments after them
  • Some directives require more configuration than can fit on one line. For those directives, you can open a block and set more parameters.
  • ...11 more annotations...
  • The first line of the Caddyfile is always the address of the site to serve
  • If the directive block is left empty, you should omit the curly braces entirely.
  • Arguments that contain whitespace must be enclosed in quotes ".
  • To configure multiple sites with a single Caddyfile, you must use curly braces around each one to separate their configurations:
  • he opening curly brace must be at the end of the same line.
  • The closing curly brace must be on its own line.
  • All directives must appear inside a site's definition.
  • Site addresses can also be defined under a specific path or have wildcards in place of individual domain labels from the left side
  • using a path in your site address will route requests by longest matching prefix.
  • Use of environment variables is allowed in addresses and arguments. They must be enclosed in curly braces,
  • you may not specify the same site address more than once
  • 張 旭 on 12 Sep 18
     
    "Directives"
張 旭

What's the Docker Swarm "-advertise-addr"? - Blog | BoxBoat - 0 views

boxboat.com/...ts-docker-swarm-advertise-addr

docker swarm networking

shared by 張 旭 on 11 Sep 18 - No Cached
  • To put it simply, the --advertise-addr is the address other nodes in the Docker swarm use to connect into your node.
  • a port number which defaults to 2377
  • The --listen-addr is the address that the swarm service listens on for incoming connections.
  • ...2 more annotations...
  • The default for --listen-addr is to listen on all interfaces on TCP port 2377 (0.0.0.0:2377)
  • Depending on your network architecture, you may want your swarm management interface only accessible on a management network that could be separate from a data and/or public network that are each attached to a physical server.
張 旭

Manage nodes in a swarm | Docker Documentation - 0 views

docs.docker.com/...manage-nodes

docker swarm system

shared by 張 旭 on 07 Sep 18 - No Cached
  • Drain means the scheduler doesn’t assign new tasks to the node. The scheduler shuts down any existing tasks and schedules them on an available node.
  • Reachable means the node is a manager node participating in the Raft consensus quorum. If the leader node becomes unavailable, the node is eligible for election as the new leader.
  • If a manager node becomes unavailable, you should either join a new manager node to the swarm or promote a worker node to be a manager.
  • ...8 more annotations...
  • docker node inspect self --pretty
  • docker node update --availability drain node
  • use node labels in service constraints
  • The labels you set for nodes using docker node update apply only to the node entity within the swarm
  • node labels can be used to limit critical tasks to nodes that meet certain requirements
  • promote a worker node to the manager role
  • demote a manager node to the worker role
  • If the last manager node leaves the swarm, the swarm becomes unavailable requiring you to take disaster recovery measures.
張 旭

Swarm task states | Docker Documentation - 0 views

docs.docker.com/...swarm-task-states

docker swarm system

shared by 張 旭 on 07 Sep 18 - No Cached
  • Each service can start multiple tasks.
  • Tasks are execution units that run once to completion.
  • The task progresses forward through a number of states, and its state doesn’t go backward.
« First ‹ Previous 401 - 420 of 1422 Next › Last »
Showing 20▼ items per page