Docker basic CheatSheet

https://docs.docker.com/get-started/

  • Install Docker:
  • Test Docker: docker run hello-world
  • Help:
    • docker –version
    • docker –help
    • docker COMMAND –help
  • Commands:
    • Show available images: docker images
    • Show containers: docker ps (docker container ls)
    • Manage containers:
      • List: docker container ls
      • Stop: docker container stop dsa34ewqe
      • Force stop: docker container kill dsa34ewqe
      • Remove: docker container rm dsa34ewqe
      • Execute bash: docker exec -it dsa34ewqe bash
      • Remove
    • Manage images:
      • List image: docker image ls
      • Remove image: docker rmi ubuntu/latest
      • Remove all images: docker rmi $(docker images -a -q)
      • Dangling images:
        • List: docker images -f dangling=true
        • Delete: docker images purge
      • Create image: docker build -t friendlyhello .
      • Run image:
        • docker run -d -p 4000:80 friendlyhello
        • docker run -d -p 4000:80 cadvga/get-started:part2
    • Manage compose:
      • docker-compose up -d

Elastic Search API quick reference guide

Index APIs

  • Create index: PUT /index_name
    • Can have JSON body to specify: Settings, Mappings, Aliases.
  • Check index existence: HEAD /index_name
  • Get index information: GET /index_name
  • Get index documents: GET /index_name/_search
  • Get index mappings: GET /index_name/_mappings
  • Delete index: DELETE /index_name
  • Delete documents: POST /index_name/_delete_by_query
  • Get settings: GET /{index}/_settings
  • Update settings: PUT /{index}/_settings

Cluster APIs

  • Cluster Health:
    • GET /_cluster/health
    • GET /_cluster/health/idx1,idx2 (Specified indices)
  • Cluster stats: GET /_cluster/stats
  • Cluster state: GET /_cluster/state
  • Nodes statistics: GET /_nodes/stats
  • Nodes info: GET /_nodes

Cat APIs

  • Command: GET /_cat/command_name
    Parameter:

    • v: turn on verbose (header) output.
    • help: show available columns.
    • h: limit the output columns.
    • … (see cat APIs) for more details.
  • List of all command with: GET /_cat

Useful slang to communicate with data scientists

  • Definition: A precise and unambiguous description of the meaning of a mathematical term. (Everybody knows that…)
  • Claim:Assertion that is then proved.  It is often used like an informal lemma. (I say…)
  • Axiom/Postulate: A statement that is assumed to be true without proof. (Believe me when I say…)
  • Lemma: A lemma is a useful observation that serves as a stepping stone to understand theorems. (I see…)
  • Conjecture: A conjecture is a guess mostly based on observations. (I guess…)
  • Hypothesis: A hypothesis is a conjecture with lots of partial evidences and significant consequences. (I believe…)
  • Theorem: A theorem is a single essential contribution to a theory (I know…)
  • Corollary: A result in which the (usually short) proof relies heavily on a given (ergo…)
  • Theory: This is how it works, based on this theorems (It is…)
  • Paradox: A statement that can be shown, using a given set of axioms and definitions, to be both true and false (WTF!)
  • […]
  • Grand Unified Theory of Everything: The ÜBER THEORY. (Oh my God… it is full of stars. Look…a Higgs Boson!)

Git-Flow alternative to support multiple versions of a product

Git-Flow works very well for a scenario where devs mantain & evolve a software with a single instance on production (i.e. http://www.virgingames.com). git

But imagine a scenario where devs develop a software that has different versions installed in different clients and devs have to give some support to old versions. (i.e. Visual Studio) while evolving the latest. Devs have to:

  • Mantain version 1.0 of your software (critical bug fixing) [In our example VS 2013]
  • Mantain version 1.1 of your software (critical bug fixing) [In our example VS 2015]
  • Develop version 1.2 (new features) [In our example VS 2017]

Git-Flow doesn’t support that scenario. Here is my solution, a git flow variant with feature branches and multiple “Master” branches called Release Branches.

Git-flowAlternative

  • Feature Branches and Dev branch works like git-flow.
  • Version 1.0
    • First release (r1.0) is done by creating a branch.
    • Evolutive development continues in Dev branch (and feature branches)
    • It is critical that no evolutive development is done in Release Branch r1.0 so if user wants a new feature he has to wait to r1.1 version.
    • If a critical bug is found in r1.0 version it can be fixed there.
    • If the critical bug is affecting dev, bug fix must be merged to dev branch.
    • If the critical bug is complex a small hot-fix branch can be created (like a feature branch)
  • Version 1.1
    • When next version (r1.1) is ready a new branch is created [Same as previous version]
    • Old branch (r1.0) is kept while we have still users on that version.
    • Once version 1.0 (r1.0) is declared obsolete, users with bugs must install a higher version.
  • Version 1.2
    • Same as version 1.1
  • Etc.

Function to prepare Machine.config

This PowerShell script “prepare” machine.config by:

  • Create appSettings.config and link it in machine.config
  • Create connectionStrings.config and link it in machine.config
  • Add proxy settings

Code:

 

 

 

 

 

 

Main base Powershell script (with Azure)

Example of PowerShell Main base script with detection of PowerShell version and Azure PowerShell version.

 

 

PowerShell new features.

PowerShell 5.0 (Windows Management Framework 5.0)

  • By default in Windows 10 & Windows Server 2016 Technical Preview.
  • Remote Script Debugging in ISE 🙂
  • Transcription works in ISE by default
  • .NET enumerations.
  • Improved DSC.

PowerShell 4.0

  • By default in Windows 8.1 & Windows Server 2012 R2
  • DSC: Desired State Configuration
  • Remote Script Debugging in console (no ISE)
  • Improved Invoke-RestMethod and Invoke-WebRequest to specify headers.

PowerShell 3.0

  • By default in Windows 8 & Windows Server 2012
  • Improved ISE: IntelliSense
  • Improved remote PowerShell ( New-PSSession)
  • Module Auto-Load
  • Invoke-RestMethod and Invoke-WebRequest
  • Ordered Hashtables
  • Scheduled jobs

The James White Manifesto

Taken from websages blog.

    == Rules ==
On Infrastructure
– There is one system, not a collection of systems.
– The desired state of the system should be a known quantity.
– The “known quantity” must be machine parseable.
– The actual state of the system must self-correct to the desired state.
– The only authoritative source for the actual state of the system is the system.
– The entire system must be deployable using source media and text files.

On Buying Software
– Keep the components in the infrastructure simple so it will be better understood.
– All products must authenticate and authorize from external, configurable sources.
– Use small tools that interoperate well, not one “do everything poorly” product.
– Do not implement any product that no one in your organization has administered.
– “Administered” does not mean saw it in a rigged demo, online or otherwise.
– If you must deploy the product, hire someone who has implemented it before to do so.

On Automation
– Do not author any code you would not buy.
– Do not implement any product that does not provide an API.
– The provided API must have all functionality that the application provides.
– The provided API must be tailored to more than one language and platform.
– Source code counts as an API, and may be restricted to one language or platform.
– The API must include functional examples and not requre someone to be an expert on the product to use.
– Do not use any product with configurations that are not machine parseable and machine writeable.
– All data stored in the product must be machine readable and writeable by applications other than the product itself.
– Writing hacks around the deficiencies in a product should be less work than writing the product’s functionality.

In general
– Keep the disparity in your architecture to an absolute minimum.
– Use Set Theory to accomplish this.
– Do not improve manual processes if you can automate them instead.
– Do not buy software that requires bare-metal.
– Manual data transfers and datastores maintained manually are to be avoided.