Larvata

Packer needs to decide on a port to use for VNC when building remotely.

vnc_disable_password - This must be set to "true" when using VNC with ESXi 6.5 or 6.7

remote_type (string) - The type of remote machine that will be used to build this VM rather than a local desktop product. The only value accepted for this currently is esx5. If this is not set, a desktop product will be used. By default, this is not set.

Functions perform operations on and within strings

the {{timestamp}} function can be used in any string to generate the current timestamp.

pwd - The working directory while executing Packer.

template_dir - The directory to the template for the build.

uuid - Returns a random UUID.

user - Specifies a user variable.

Template variables are special variables automatically set by Packer at build time.

User variables are available globally within the rest of the template.

The env function is available only within the default value of a user variable, allowing you to default a user variable to an environment variable.

To set user variables from the command line, the -var flag is used as a parameter to packer build (and some other commands).

Variables can also be set from an external JSON file. The -var-file flag reads a file containing a key/value mapping of variables to values and sets those variables.

-var-file=

sensitive variables won't get printed to the logs by adding them to the "sensitive-variables" list within the Packer template

validate the template by running packer validate example.json. This command checks the syntax as well as the configuration values to verify they look valid.

At the end of running packer build, Packer outputs the artifacts that were created as part of the build.

Packer only builds images. It does not attempt to manage them in any way.

.tf files can accept values from input variables.

variable definitions can have default values assigned to them.

values are stored in separate files with the .tfvars extension.

looks through the working directory for a file named terraform.tfvars, or for files with the .auto.tfvars extension.

add the terraform.tfvars file to your .gitignore file and keep it out of version control.

include an example terraform.tfvars.example in your Git repository with all of the variable names recorded (but none of the values entered).

terraform apply -var-file=myvars.tfvars

Terraform allows you to keep input variable values in environment variables.

If Terraform does not find a default value for a defined variable; or a value from a .tfvars file, environment variable, or CLI flag; it will prompt you for a value before running an action

state file contains a JSON object that holds your managed infrastructure’s current state

state is a snapshot of the various attributes of your infrastructure at the time it was last modified

Some backends, like Consul, also allow for state locking. If one user is applying a state, another user will be unable to make any changes.

Terraform backends allow the user to securely store their state in a remote location, such as a key/value store like Consul, or an S3 compatible bucket storage like Minio.

at minimum the repository should be private.

When a plugin cache directory is enabled, the terraform init command will still access the plugin distribution server to obtain metadata about which plugins are available, but once a suitable version has been selected it will first check to see if the selected plugin is already available in the cache directory.

When possible, Terraform will use hardlinks or symlinks to avoid storing a separate copy of a cached plugin in multiple directories.

Terraform will never itself delete a plugin from the plugin cache once it's been placed there.

Kubernetes is fully controlled through this API

the main job of kubectl is to carry out HTTP requests to the Kubernetes API

Kubernetes maintains an internal state of resources, and all Kubernetes operations are CRUD operations on these resources.

Kubernetes is a fully resource-centred system

Kubernetes API reference is organised as a list of resource types with their associated operations.

This is how kubectl works for all commands that interact with the Kubernetes cluster.

kubectl simply makes HTTP requests to the appropriate Kubernetes API endpoints.

it's totally possible to control Kubernetes with a tool like curl by manually issuing HTTP requests to the Kubernetes API.

Kubernetes consists of a set of independent components that run as separate processes on the nodes of a cluster.

components on the master nodes

Storage backend: stores resource definitions (usually etcd is used)

API server: provides Kubernetes API and manages storage backend

Controller manager: ensures resource statuses match specifications

Scheduler: schedules Pods to worker nodes

component on the worker nodes

Kubelet: manages execution of containers on a worker node

triggers the ReplicaSet controller, which is a sub-process of the controller manager.

the scheduler, who watches for Pod definitions that are not yet scheduled to a worker node.

creating and updating resources in the storage backend on the master node.

However, these components do not access the storage backend directly, but only through the Kubernetes API.

All other Kubernetes components and users read, watch, and manipulate the state (i.e. resources) of Kubernetes through the Kubernetes API

The storage backend stores the state (i.e. resources) of Kubernetes.

command completion is a shell feature that works by the means of a completion script.

A completion script is a shell script that defines the completion behaviour for a specific command. Sourcing a completion script enables completion for the corresponding command.

kubectl completion zsh

/etc/bash_completion.d directory (create it, if it doesn't exist)

source <(kubectl completion bash)

source <(kubectl completion zsh)

autoload -Uz compinit compinit

the API reference, which contains the full specifications of all resources.

kubectl api-resources

displays the resource names in their plural form (e.g. deployments instead of deployment). It also displays the shortname (e.g. deploy) for those resources that have one. Don't worry about these differences. All of these name variants are equivalent for kubectl.

.spec

custom columns output format comes in. It lets you freely define the columns and the data to display in them. You can choose any field of a resource to be displayed as a separate column in the output

kubectl get pods -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

kubectl explain pod.spec.

kubectl explain pod.metadata.

browse the resource specifications and try it out with any fields you like!

with kubectl explain, only a subset of the JSONPath capabilities is supported

Many fields of Kubernetes resources are lists, and this operator allows you to select items of these lists. It is often used with a wildcard as [*] to select all items of the list.

kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

a Pod may contain more than one container.

The availability zones for each node are obtained through the special failure-domain.beta.kubernetes.io/zone label.

kubectl get nodes -o yaml kubectl get nodes -o json

The default kubeconfig file is ~/.kube/config

with multiple clusters, then you have connection parameters for multiple clusters configured in your kubeconfig file.

overwrite the default kubeconfig file with the --kubeconfig option for every kubectl command.

Namespace: the namespace to use when connecting to the cluster

a one-to-one mapping between clusters and contexts.

When kubectl reads a kubeconfig file, it always uses the information from the current context.

just change the current context in the kubeconfig file

kubectl also provides the --cluster, --user, --namespace, and --context options that allow you to overwrite individual elements and the current context itself, regardless of what is set in the kubeconfig file.

for switching between clusters and namespaces is kubectx.

kubectl config get-contexts

just have to download the shell scripts named kubectl-ctx and kubectl-ns to any directory in your PATH and make them executable (for example, with chmod +x)

kubectl proxy

kubectl get roles

kubectl get pod

Kubectl plugins are distributed as simple executable files with a name of the form kubectl-x. The prefix kubectl- is mandatory,

To install a plugin, you just have to copy the kubectl-x file to any directory in your PATH and make it executable (for example, with chmod +x)

krew itself is a kubectl plugin

check out the kubectl-plugins GitHub topic

The executable can be of any type, a Bash script, a compiled Go program, a Python script, it really doesn't matter. The only requirement is that it can be directly executed by the operating system.

kubectl plugins can be written in any programming or scripting language.

you can write more sophisticated plugins with real programming languages, for example, using a Kubernetes client library. If you use Go, you can also use the cli-runtime library, which exists specifically for writing kubectl plugins.

a kubeconfig file consists of a set of contexts

changing the current context means changing the cluster, if you have only a single context per cluster.

manually write state with terraform state push. This is extremely dangerous and should be avoided if possible. This will overwrite the remote state.

The "lineage" is a unique ID assigned to a state when it is created.

Every state has a monotonically increasing "serial" number.

A Terraform Provider is responsible for understanding API interactions between and exposing the resources from a given Infrastructure, Platform, or SaaS offering to Terraform.

HashiCorp Configuration Language (HCL)

the provider credentials are passed in at the top of the script to connect to the vSphere account.

modules— a way to encapsulate infrastructure resources into a reusable format.

Communication between pods is more complicated, however, and requires a separate networking component that can transparently route traffic from a pod on one node to a pod on another.

pod network plugins. For this cluster, you will use Flannel, a stable and performant option.

Passing the argument --pod-network-cidr=10.244.0.0/16 specifies the private subnet that the pod IPs will be assigned from.

kubectl apply -f descriptor.[yml|json] is the syntax for telling kubectl to create the objects described in the descriptor.[yml|json] file.

deploy Nginx using Deployments and Services

NodePort, a scheme that will make the pod accessible through an arbitrary port opened on each node of the cluster

load balancing requests to multiple pods

Pods are ubiquitous in Kubernetes, so understanding them will facilitate your work

how controllers such as deployments work since they are used frequently in stateless applications for scaling and the automated healing of unhealthy applications.

Understanding the types of services and the options they have is essential for running both stateless and stateful applications.

find . -type f | while read F ; do echo $F ; done 不但可以容忍空格，而且还更快。

防御式编程，在正式执行命令前，把相关的东西都检查好，比如，文件目录有没有存在。

shift takes these arguments and removes the first one, shifting each of the rest down by one place in line.

on any of the options that accept an argument, that argument will be stored in the variable $OPTARG automagically for you.

getopts command