Skip to main content

Home/ Larvata/ Group items tagged devops

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

打造高效的工作环境 - Shell 篇 | | 酷 壳 - CoolShell - 0 views

coolshell.cn/19219.html

system shell linux devops

shared by 張 旭 on 25 Mar 19 - No Cached
  • 对于一些字符串变量，使用引号括起，避免其中有空格或是别的什么诡异字符。
  • 使用 $() 而不是 “ 来获得命令行的输出，主要原因是易读。
  • 对于 rm -rf 这样的高危操作，需要检查后面的变量名是否为空
  • ...2 more annotations...
  • find . -type f | while read F ; do echo $F ; done 不但可以容忍空格，而且还更快。
  • 防御式编程，在正式执行命令前，把相关的东西都检查好，比如，文件目录有没有存在。
張 旭

Using Infrastructure as Code to Automate VMware Deployments - 1 views

www.hashicorp.com/...to-automate-vmware-deployments

vmware devops system terraform

shared by 張 旭 on 28 Mar 19 - No Cached
  • Infrastructure as code is at the heart of provisioning for cloud infrastructure marking a significant shift away from monolithic point-and-click management tools.
  • infrastructure as code enables operators to take a programmatic approach to provisioning.
  • provides a single workflow to provision and maintain infrastructure and services from all of your vendors, making it not only easier to switch providers
  • ...5 more annotations...
  • A Terraform Provider is responsible for understanding API interactions between and exposing the resources from a given Infrastructure, Platform, or SaaS offering to Terraform.
  • write a Terraform file that describes the Virtual Machine that you want, apply that file with Terraform and create that VM as you described without ever needing to log into the vSphere dashboard.
  • 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.
  • 張 旭 on 28 Mar 19
     
    "revolutionizing"
張 旭

Data Sources - Configuration Language - Terraform by HashiCorp - 0 views

www.terraform.io/...data-sources.html

terraform devops variable

shared by 張 旭 on 07 Apr 19 - No Cached
  • refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module.
  • A data block requests that Terraform read from a given data source ("aws_ami") and export the result under the given local name ("example").
  • A data source is accessed via a special kind of resource known as a data resource
  • 張 旭 on 07 Apr 19
     
    "refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module."
張 旭

Introduction - Packer by HashiCorp - 0 views

www.packer.io/index.html

vmware system packer devops virtualization

shared by 張 旭 on 03 Apr 19 - No Cached
  • A machine image is a single static unit that contains a pre-configured operating system and installed software which is used to quickly create new running machines.
  • 張 旭 on 03 Apr 19
     
    "A machine image is a single static unit that contains a pre-configured operating system and installed software which is used to quickly create new running machines."
張 旭

Backends: State Storage and Locking - Terraform by HashiCorp - 0 views

www.terraform.io/...state.html

terraform devops system storage status

shared by 張 旭 on 07 Apr 19 - No Cached
  • Backends determine where state is stored.
  • backends happen to provide locking: local via system APIs and Consul via locking APIs.
  • manually retrieve the state from the remote state using the terraform state pull command
  • ...3 more annotations...
  • 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.
  • 張 旭 on 07 Apr 19
     
    "Backends determine where state is stored."
張 旭

Backends: Configuration - Terraform by HashiCorp - 0 views

www.terraform.io/...config.html

terraform devops system

shared by 張 旭 on 07 Apr 19 - No Cached
  • merged configuration is stored on disk in the .terraform directory, which should be ignored from version control.
  • When using partial configuration, Terraform requires at a minimum that an empty backend configuration is specified in one of the root Terraform configuration files, to specify the backend type.
  • 張 旭 on 07 Apr 19
     
    "merged configuration is stored on disk in the .terraform directory, which should be ignored from version control."
張 旭

User Variables - Templates - Packer by HashiCorp - 0 views

www.packer.io/...user-variables.html

packer virtualization image devops

shared by 張 旭 on 12 Apr 19 - No Cached
  • User variables allow your templates to be further configured with variables from the command-line, environment variables, Vault, or files.
  • define it either within the variables section within your template, or using the command-line -var or -var-file flags.
  • If the default value is null, then the user variable will be required.
  • ...7 more annotations...
  • 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.
  • As Packer doesn't run inside a shell, it won't expand ~
  • 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
張 旭

Boosting your kubectl productivity ♦︎ Learnk8s - 0 views

learnk8s.io/...kubectl-productivity

devops kubernetes kubectl

shared by 張 旭 on 09 Apr 19 - No Cached
  • kubectl is your cockpit to control Kubernetes.
  • kubectl is a client for the Kubernetes API
  • Kubernetes API is an HTTP REST API.
  • ...75 more annotations...
  • This API is the real Kubernetes user interface.
  • Kubernetes is fully controlled through this API
  • every Kubernetes operation is exposed as an API endpoint and can be executed by an HTTP request to this endpoint.
  • 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.
  • The kubelet of the worker node your ReplicaSet Pods have been scheduled to instructs the configured container runtime (which may be Docker) to download the required container images and run the containers.
  • Kubernetes components (except the API server and the storage backend) work by watching for resource changes in the storage backend and manipulating resources in the storage backend.
  • However, these components do not access the storage backend directly, but only through the Kubernetes API.
    • 張 旭
      張 旭 on 09 Apr 19
       
      很精彩，相互之間都是使用 API call 溝通，良好的微服務行為。
  • double usage of the Kubernetes API for internal components as well as for external users is a fundamental design concept of Kubernetes.
  • 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!
  • JSONPath is a language to extract data from JSON documents (it is similar to XPath for XML).
  • 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.
  • Within a cluster, you can set up multiple namespaces (a namespace is kind of "virtual" clusters within a physical cluster)
  • 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
  • to switch to another namespace in the same cluster, you can change the value of the namespace element of the current context
  • 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.
張 旭

Providers - Configuration Language - Terraform by HashiCorp - 0 views

www.terraform.io/...providers.html

terraform config devops

shared by 張 旭 on 11 Apr 19 - No Cached
  • By default, terraform init downloads plugins into a subdirectory of the working directory so that each working directory is self-contained.
  • Terraform optionally allows the use of a local directory as a shared plugin cache, which then allows each distinct plugin binary to be downloaded only once.
  • directory must already exist before Terraform will cache plugins; Terraform will not create the directory itself.
  • ...3 more annotations...
  • 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.
  • 張 旭 on 11 Apr 19
     
    "By default, terraform init downloads plugins into a subdirectory of the working directory so that each working directory is self-contained."
張 旭

Build an Image - Getting Started - Packer by HashiCorp - 0 views

www.packer.io/...build-image.html

devops packer virtualization image

shared by 張 旭 on 12 Apr 19 - No Cached
  • The configuration file used to define what image we want built and how is called a template in Packer terminology.
  • JSON struck the best balance between human-editable and machine-editable, allowing both hand-made templates as well as machine generated templates to easily be made.
  • keeping your secret keys out of the template
  • ...3 more annotations...
  • 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.
張 旭

Template Engine - Templates - Packer by HashiCorp - 0 views

www.packer.io/...engine.html

packer virtualization image devops template engine

shared by 張 旭 on 12 Apr 19 - No Cached
  • All strings within templates are processed by a common Packer templating engine, where variables and functions can be used to modify the value of a configuration parameter at runtime.
  • Anything template related happens within double-braces: {{ }}.
  • Functions are specified directly within the braces, such as {{timestamp}}
  • ...8 more annotations...
  • Template variables are prefixed with a period and capitalized, such as {{.Variable}}.
  • 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.
張 旭

VMware ISO - Builders - Packer by HashiCorp - 0 views

www.packer.io/...vmware-iso.html

packer virtualization image devops vmware

shared by 張 旭 on 12 Apr 19 - No Cached
  • Packer can use a remote VMware Hypervisor to build the virtual machine.
  • enable GuestIPHack
  • When using a remote VMware Hypervisor, the builder still downloads the ISO and various files locally, and uploads these to the remote machine.
  • ...3 more annotations...
  • 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.
  • 張 旭 on 12 Apr 19
     
    "Packer can use a remote VMware Hypervisor to build the virtual machine."
張 旭

Secrets Management with Terraform - 0 views

www.linode.com/...rets-management-with-terraform

terraform config devops security

shared by 張 旭 on 12 Apr 19 - No Cached
  • Terraform is an Infrastructure as Code (IaC) tool that allows you to write declarative code to manage your infrastructure.
  • Keeping Secrets Out of .tf Files
  • .tf files contain the declarative code used to create, manage, and destroy infrastructure.
  • ...17 more annotations...
  • .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.
  • the prefix TF_VAR_
  • 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
  • sensitive information used to generate your Terraform state can be stored as plain text in the terraform.tfstate file.
  • Avoid checking your terraform.tfstate file into your version control repository.
  • 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.
張 旭

Introduction to CI/CD with GitLab | GitLab - 0 views

docs.gitlab.com/...index.html

devops CI

shared by 張 旭 on 16 Apr 19 - No Cached
  • deploying code changes at every small iteration, reducing the chance of developing new code based on bugged or failed previous versions
  • based on automating the execution of scripts to minimize the chance of introducing errors while developing applications.
  • For every push to the repository, you can create a set of scripts to build and test your application automatically, decreasing the chance of introducing errors to your app.
  • ...5 more annotations...
  • checked automatically but requires human intervention to manually and strategically trigger the deployment of the changes.
  • instead of deploying your application manually, you set it to be deployed automatically.
  • .gitlab-ci.yml, located in the root path of your repository
  • all the scripts you add to the configuration file are the same as the commands you run on a terminal in your computer.
  • GitLab will detect it and run your scripts with the tool called GitLab Runner, which works similarly to your terminal.
  • 張 旭 on 16 Apr 19
     
    "deploying code changes at every small iteration, reducing the chance of developing new code based on bugged or failed previous versions"
張 旭

Intro to deployment strategies: blue-green, canary, and more - DEV Community - 0 views

dev.to/...blue-green-canary-and-more-3a3

devops deploy system micro service

shared by 張 旭 on 23 Nov 18 - No Cached
  • using a service-oriented architecture and microservices approach, developers can design a code base to be modular.
  • Modern applications are often distributed and cloud-based
  • different release cycles for different components
  • ...20 more annotations...
  • the abstraction of the infrastructure layer, which is now considered code. Deployment of a new application may require the deployment of new infrastructure code as well.
  • "big bang" deployments update whole or large parts of an application in one fell swoop.
  • Big bang deployments required the business to conduct extensive development and testing before release, often associated with the "waterfall model" of large sequential releases.
  • Rollbacks are often costly, time-consuming, or even impossible.
  • In a rolling deployment, an application’s new version gradually replaces the old one.
  • new and old versions will coexist without affecting functionality or user experience.
  • Each container is modified to download the latest image from the app vendor’s site.
  • two identical production environments work in parallel.
  • Once the testing results are successful, application traffic is routed from blue to green.
  • In a blue-green deployment, both systems use the same persistence layer or database back end.
  • You can use the primary database by blue for write operations and use the secondary by green for read operations.
  • Blue-green deployments rely on traffic routing.
  • long TTL values can delay these changes.
  • The main challenge of canary deployment is to devise a way to route some users to the new application.
  • Using an application logic to unlock new features to specific users and groups.
  • With CD, the CI-built code artifact is packaged and always ready to be deployed in one or more environments.
  • Use Build Automation tools to automate environment builds
  • Use configuration management tools
  • Enable automated rollbacks for deployments
  • An application performance monitoring (APM) tool can help your team monitor critical performance metrics including server response times after deployments.
張 旭

Reusing Config - CircleCI - 0 views

circleci.com/...reusing-config

circle CI config deploy devops

shared by 張 旭 on 26 Nov 18 - No Cached
  • Change the version key to 2.1 in your .circleci/config.yml file and commit the changes to test your build.
  • Reusable commands are invoked with specific parameters as steps inside a job.
  • Commands can use other commands in the scope of execution
  • ...19 more annotations...
  • Executors define the environment in which the steps of a job will be run.
  • Executor declarations in config outside of jobs can be used by all jobs in the scope of that declaration, allowing you to reuse a single executor definition across multiple jobs.
  • It is also possible to allow an orb to define the executor used by all of its commands.
  • When invoking an executor in a job any keys in the job itself will override those of the executor invoked.
  • Steps are used when you have a job or command that needs to mix predefined and user-defined steps.
  • Use the enum parameter type when you want to enforce that the value must be one from a specific set of string values.
  • Use an executor parameter type to allow the invoker of a job to decide what executor it will run on
  • invoke the same job more than once in the workflows stanza of config.yml, passing any necessary parameters as subkeys to the job.
  • If a job is declared inside an orb it can use commands in that orb or the global commands.
  • To use parameters in executors, define the parameters under the given executor.
  • Parameters are in-scope only within the job or command that defined them.
  • A single configuration may invoke a job multiple times.
  • Every job invocation may optionally accept two special arguments: pre-steps and post-steps.
  • Pre and post steps allow you to execute steps in a given job without modifying the job.
  • conditions are checked before a workflow is actually run
  • you cannot use a condition to check an environment variable.
  • Conditional steps may be located anywhere a regular step could and may only use parameter values as inputs.
  • A conditional step consists of a step with the key when or unless. Under this conditional key are the subkeys steps and condition
  • A condition is a single value that evaluates to true or false at the time the config is processed, so you cannot use environment variables as conditions
‹ Previous 21 - 40 of 85 Next › Last »
Showing 20▼ items per page