Minikube реализует локальный кластер Kubernetes на MacOS или Linux ОС. Основные цели minikube — стать лучшим инструментом для разработки локальных приложений Kubernetes и поддерживать все подходящие функции Kubernetes.

Установка minikube на MacOS

Чтобы проверить, поддерживается ли виртуализация в вашей macOS, выполните следующую команду на своем терминале:

$ sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C

Как видно с моего вывода — у меня имеется все необходимое.

-=== СПОСОБ 1 ===-

Устанавливаем homebrew, статья тут — установка homebrew

А затем можно вводить комнду:

$ brew cask install minikube

-=== СПОСОБ 2 ===-

Также можно установить его на macOS, загрузив отдельный двоичный файл:

$ sudo curl -Lo /usr/local/bin/minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
  && sudo chmod +x /usr/local/bin/minikube

Проверим версию можно так:

$ minikube version
minikube version: v1.4.0
commit: 7969c25a98a018b94ea87d949350f3271e9d64b6

Вот так вот!

Настройка minikube в Unix/Linux

Чтобы проверить, поддерживается ли виртуализация в Linux, выполните следующую команду и убедитесь, что выходные данные не пусты:

$ grep -E --color 'vmx|svm' /proc/cpuinfo

Затем стоит установить kubectl. Далее, стоит установить гипервизер, например kvm или virtualbox:

Установить Virtualbox на Centos/Fedora

Установить VirtualBox на Ubuntu/Debian или Linux Mint

Установка гипервизора KVM на Debian/Ubuntu

Например, можно выполнить установку KVM так, но для этого установим пакет:

$ sudo apt install cpu-checker && sudo kvm-ok

Если после запуска kvm-ok вы получите следующий вывод, вы можете использовать KVM на своем компьютере (в противном случае проверьте свою конфигурацию):

$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

Теперь давайте установим KVM и libvirt и добавим нашего текущего пользователя в группу libvirt для предоставления достаточных разрешений:

$ sudo apt install libvirt-clients libvirt-daemon-system qemu-kvm \
    && sudo usermod -a -G libvirt $(whoami) \
    && newgrp libvirt

После установки libvirt вы можете проверить допустимость хоста для запуска виртуальных машин с помощью инструмента virt-host-validate, который является частью libvirt:

$ sudo virt-host-validate

Ставим kubectl:

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl \
    && sudo install kubectl /usr/local/bin && rm kubectl

Если KVM используется в качестве единственного драйвера для Minikube на нашей машине, более удобно установить его в качестве драйвера по умолчанию и запускать Minikube с меньшим количеством аргументов командной строки. Следующая команда устанавливает драйвер KVM по умолчанию:

$ minikube config set vm-driver kvm2

Если вы не устанавливаете с помощью пакета, вы можете загрузить отдельный двоичный файл и использовать его:

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
  && chmod +x minikube

Вот простой способ добавить исполняемый файл Minikube к вашему пути:

$ sudo mkdir -p /usr/local/bin/ && \
install minikube /usr/local/bin/

Можно проверить версию утилиты:

$ minikube version

Установка выполнена.

Работа с minikube в Unix/Linux

Запуск очень простой:

$ minikube start

Но можно указать количество ядер и сколько оперативной памяти выделить миникубу:

$ minikube start --cpus 6 --memory 8192
😄  minikube v1.2.0 on darwin (amd64)
👍  minikube will upgrade the local cluster from Kubernetes 1.10.0 to 1.15.0
💿  Downloading Minikube ISO ...
 129.33 MB / 129.33 MB [============================================] 100.00% 0s
💡  Tip: Use 'minikube start -p <name>' to create a new cluster, or 'minikube delete' to delete this one.
🔄  Restarting existing virtualbox VM for "minikube" ...
⌛  Waiting for SSH access ...
🐳  Configuring environment for Kubernetes v1.15.0 on Docker 17.12.1-ce
💾  Downloading kubeadm v1.15.0
💾  Downloading kubelet v1.15.0
🚜  Pulling images ...
🔄  Relaunching Kubernetes v1.15.0 using kubeadm ...
⌛  Verifying: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"

PS: Запуск был выполнен на МакОС, а в качестве гипервизера был выбрал virtualbox.

Можно получить следующую ошибку:

machine does not exist

Решение:

$ minikube delete && minikube start

Чтобы проверить статус, выполните:

$ minikube status

Если есть необходимость удалить стек, выполните:

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💔  The "minikube" cluster has been deleted.

Для помощи, выполняем:

$ minikube --help
Minikube is a CLI tool that provisions and manages single-node Kubernetes clusters optimized for development workflows.

Basic Commands:
  start          Starts a local kubernetes cluster
  status         Gets the status of a local kubernetes cluster
  stop           Stops a running local kubernetes cluster
  delete         Deletes a local kubernetes cluster
  dashboard      Access the kubernetes dashboard running within the minikube cluster

Images Commands:
  docker-env     Sets up docker env variables; similar to '$(docker-machine env)'
  cache          Add or delete an image from the local cache.

Configuration and Management Commands:
  addons         Modify minikube's kubernetes addons
  config         Modify minikube config
  profile        Profile gets or sets the current minikube profile
  update-context Verify the IP address of the running cluster in kubeconfig.

Networking and Connectivity Commands:
  service        Gets the kubernetes URL(s) for the specified service in your local cluster
  tunnel         tunnel makes services of type LoadBalancer accessible on localhost

Advanced Commands:
  mount          Mounts the specified directory into minikube
  ssh            Log into or run a command on a machine with SSH; similar to 'docker-machine ssh'
  kubectl        Run kubectl

Troubleshooting Commands:
  ssh-key        Retrieve the ssh identity key path of the specified cluster
  ip             Retrieves the IP address of the running cluster
  logs           Gets the logs of the running instance, used for debugging minikube, not user code.
  update-check   Print current and latest version number
  version        Print the version of minikube

Other Commands:
  completion     Outputs minikube shell completion for the given shell (bash or zsh)

Use "minikube <command> --help" for more information about a given command.

Или конкретно для какой-то команды:

$ minikube start --help
Starts a local kubernetes cluster

Options:
      --apiserver-ips=[]: A set of apiserver IP Addresses which are used in the generated certificate for kubernetes.
This can be used if you want to make the apiserver available from outside the machine
      --apiserver-name='minikubeCA': The apiserver name which is used in the generated certificate for kubernetes.  This
can be used if you want to make the apiserver available from outside the machine
      --apiserver-names=[]: A set of apiserver names which are used in the generated certificate for kubernetes.  This
can be used if you want to make the apiserver available from outside the machine
      --apiserver-port=8443: The apiserver listening port
      --cache-images=true: If true, cache docker images for the current bootstrapper and load them into the machine.
Always false with --vm-driver=none.
      --container-runtime='docker': The container runtime to be used (docker, crio, containerd).
      --cpus=2: Number of CPUs allocated to the minikube VM.
      --cri-socket='': The cri socket path to be used.
      --disable-driver-mounts=false: Disables the filesystem mounts provided by the hypervisors
      --disk-size='20000mb': Disk size allocated to the minikube VM (format: <number>[<unit>], where unit = b, k, m or
g).
      --dns-domain='cluster.local': The cluster dns domain name used in the kubernetes cluster
      --dns-proxy=false: Enable proxy for NAT DNS requests (virtualbox driver only)
      --docker-env=[]: Environment variables to pass to the Docker daemon. (format: key=value)
      --docker-opt=[]: Specify arbitrary flags to pass to the Docker daemon. (format: key=value)
      --download-only=false: If true, only download and cache files for later use - don't install or start anything.
      --embed-certs=false: if true, will embed the certs in kubeconfig.
      --enable-default-cni=false: Enable the default CNI plugin (/etc/cni/net.d/k8s.conf). Used in conjunction with
"--network-plugin=cni".
      --extra-config=: A set of key=value pairs that describe configuration that may be passed to different components.
		The key should be '.' separated, and the first part before the dot is the component to apply the configuration to.
		Valid components are: kubelet, kubeadm, apiserver, controller-manager, etcd, proxy, scheduler
		Valid kubeadm parameters: ignore-preflight-errors, dry-run, kubeconfig, kubeconfig-dir, node-name, cri-socket,
experimental-upload-certs, certificate-key, rootfs, pod-network-cidr
      --feature-gates='': A set of key=value pairs that describe feature gates for alpha/experimental features.
      --force=false: Force minikube to perform possibly dangerous operations
      --host-dns-resolver=true: Enable host resolver for NAT DNS requests (virtualbox driver only)
      --host-only-cidr='192.168.99.1/24': The CIDR to be used for the minikube VM (virtualbox driver only)
      --hyperkit-vpnkit-sock='': Location of the VPNKit socket used for networking. If empty, disables Hyperkit
VPNKitSock, if 'auto' uses Docker for Mac VPNKit connection, otherwise uses the specified VSock (hyperkit driver only)
      --hyperkit-vsock-ports=[]: List of guest VSock ports that should be exposed as sockets on the host (hyperkit
driver only)
      --hyperv-virtual-switch='': The hyperv virtual switch name. Defaults to first found. (hyperv driver only)
      --image-mirror-country='': Country code of the image mirror to be used. Leave empty to use the global one. For
Chinese mainland users, set it to cn.
      --image-repository='': Alternative image repository to pull docker images from. This can be used when you have
limited access to gcr.io. Set it to "auto" to let minikube decide one for you. For Chinese mainland users, you may use
local gcr.io mirrors such as registry.cn-hangzhou.aliyuncs.com/google_containers
      --insecure-registry=[]: Insecure Docker registries to pass to the Docker daemon.  The default service CIDR range
will automatically be added.
      --interactive=true: Allow user prompts for more information
      --iso-url='https://storage.googleapis.com/minikube/iso/minikube-v1.4.0.iso': Location of the minikube iso.
      --keep-context=false: This will keep the existing kubectl context and will create a minikube context.
      --kubernetes-version='v1.16.0': The kubernetes version that the minikube VM will use (ex: v1.2.3)
      --kvm-gpu=false: Enable experimental NVIDIA GPU support in minikube
      --kvm-hidden=false: Hide the hypervisor signature from the guest in minikube (kvm2 driver only)
      --kvm-network='default': The KVM network name. (kvm2 driver only)
      --kvm-qemu-uri='qemu:///system': The KVM QEMU connection URI. (kvm2 driver only)
      --memory='2000mb': Amount of RAM allocated to the minikube VM (format: <number>[<unit>], where unit = b, k, m or
g).
      --mount=false: This will start the mount daemon and automatically mount files into minikube.
      --mount-string='/Users:/minikube-host': The argument to pass the minikube mount command on start.
      --native-ssh=true: Use native Golang SSH client (default true). Set to 'false' to use the command line 'ssh'
command when accessing the docker machine. Useful for the machine drivers when they will not start with 'Waiting for
SSH'.
      --network-plugin='': The name of the network plugin.
      --nfs-share=[]: Local folders to share with Guest via NFS mounts (hyperkit driver only)
      --nfs-shares-root='/nfsshares': Where to root the NFS Shares, defaults to /nfsshares (hyperkit driver only)
      --no-vtx-check=false: Disable checking for the availability of hardware virtualization before the vm is started
(virtualbox driver only)
      --registry-mirror=[]: Registry mirrors to pass to the Docker daemon
      --service-cluster-ip-range='10.96.0.0/12': The CIDR to be used for service cluster IPs.
      --uuid='': Provide VM UUID to restore MAC address (hyperkit driver only)
      --vm-driver='': Driver is one of: [virtualbox parallels vmwarefusion hyperkit vmware] (defaults to virtualbox)
      --wait=true: Wait until Kubernetes core services are healthy before exiting.
      --wait-timeout=6m0s: max time to wait per Kubernetes core services to be healthy.

Usage:
  minikube start [flags] [options]

Use "minikube start options" for a list of global command-line options (applies to all commands).

В данной утилите, нет ничего сложного чтобы понять как с ней работать. Для своих целей, я использовать запуск, остановку и удаления стека. Если будут мысли о том что дополнить в статье — обязательно добавлю.

Давайте проверим, работает ли кластер Kubernetes:

$ kubectl get nodes

Теперь давайте запустим простой пример приложения (в нашем случае nginx):

$ kubectl create deployment nginx --image=nginx

Давайте также проверим, правильно ли настроены pods в Kubernetes:

$ kubectl get pods

Вот и все, статья «Установка minikube в Unix/Linux» завершена.

Контейнер, запускается всегда от пользователя root, но бывает так, что в Dockerfile прописывают юзера для работы внутри контейнера. И тогда, когда попытаться использовать другого юзера, выдаст ввод пароля, который возможно не знаете, например:

$ docker exec -ti jenkins /bin/bash
 jenkins@6350b7b8729c:/$ su -
 Password:

Как видно с команды выше, я запустил дженкинс. У контейнера имеется пользователь (тоже дженкинс), но я не знаю от него пароль. Решение — это использовать параметр который выставит нужного юзера при старте контейнера:

$ docker exec -it -u your_container_user your_conatainer container_command

Или:

$ docker exec -it --user your_container_user your_conatainer container_command 

Приведу пример с дженкинсом:

$ docker exec -it -u root jenkins /bin/bash

При данной команде, я подключусь к контейнеру как root-юзер.

Да, но если есть необходимость запустить сам контейнер от другого пользователя, то стоит использовать:

$ sudo -u your_user "docker run -d     --name jenkins     --hostname jenkins.local     -p 8080:8080 -p 50000:50000     --restart always     -v /usr/local/jenkins/data_2:/var/jenkins_home     --dns=10.17.0.3     --dns=10.17.0.4     --dns=1.1.1.1     --dns=74.82.42.42     --add-host=gitlab_local_docker:172.168.0.66     jenkins/jenkins:latest"

Или, сначала переключится в пользователя и запустить от него докер:

$ su YOUR_USER 

И потом, можно вот так:

docker run -d \
     --name jenkins \
     --hostname jenkins.local \
     -p 8080:8080 -p 50000:50000 \
     --restart always \
     -v /usr/local/jenkins/data_2:/var/jenkins_home \
     --dns=10.17.0.3 \
     --dns=10.17.0.4 \
     --dns=1.1.1.1 \
     --dns=74.82.42.42 \
     --add-host=gitlab_local_docker:172.168.0.66 \
     jenkins/jenkins:latest 

Вот и все, статья «Запустить Docker контейнер от пользователя в Unix/Linux» завершена.

Установка Helm в Unix/Linux

Helm — это бинарный файл, который управляет развертыванием chart-ов (диаграм) в Kubernetes.  Что такое chart или диаграмма? А это собственно, — упакованная единица вашего программного обеспечения для деплоя в kubernetes. Он содержит все определения ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes (Это что-то подобное как в  Homebrew, Apt dpkg или RPM Yum).

Helm помогает вам управлять приложениями Kubernetes — Helm Charts помогает вам определять, устанавливать и обновлять даже самое сложное приложения в k8s.

Репозиторий (Repo) — это место, где диаграммы (chart-ы) могут хранится и использоваться. Это похоже на архив CPAN Perl или базу данных Fedora пакетов, но для Kubernetes.

Выпуск (Release) представляет собой экземпляр диаграммы, выполняющейся в кластере Kubernetes. Одна диаграмма может быть установлена много раз на один и тот же k8s кластер.

Установка Helm в Unix/Linux

Так как helm нужен для помощи с k8s, то нужно установить Kubernetes. Если еще не сделали, то вот полезные маны:

Установка Kubernetes в Unix/Linux

Установка Kubernetes кластера в Unix/Linux

Я буду использовать minikube (но это не столь важно) для стоих локальных тестов. И так, давайте приступим к установке хелма и посмотрим как можно работать с ним.

-=== СПОСОБ 1 ===-

Можно вытянуть мастер ветку с гита через wget/curl, например:

$ wget https://codeload.github.com/helm/helm/zip/master -O /usr/local/src/helm.zip && unzip /usr/local/src/helm.zip -d /usr/local/src

Или через git:

$ cd /usr/local/src && git clone https://github.com/helm/helm.git

Перейдем в папку:

$ cd helm

И выполняем билд:

$ make bootstrap build

Готово!

-=== СПОСОБ 2 ===-

Зайти на сайт и выкачать последний релиз-кандидат. Я люблю автоматизацию и по этому захотелось найти способ получить последние релизы прям из терминала, вот команда:

$ curl -s --list-only https://github.com/helm/helm/releases | grep -E "https://storage.googleapis.com/kubernetes-helm/helm-"| grep -E "MacOS|Linux"| cut -d">" -f2| cut -d"=" -f2| cut -d '"' -f2

Покажет примерно вот такое:

https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-darwin-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-arm.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-arm64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-386.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-ppc64le.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-s390x.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-darwin-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-linux-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-linux-arm.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-linux-arm64.tar.gz

.............

Находим необходимую ссылку и качаем

$ wget https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-darwin-amd64.tar.gz -O /usr/local/src/helm-v2.11.0-darwin-amd64.tar.gz

Получаем бинарник из архива:

$ tar xfvz /usr/local/src/helm-v2.11.0-darwin-amd64.tar.gz -C /usr/local/src

Перемещаем бинарник:

$ mv darwin-amd64/helm /usr/local/bin/helm && sudo chmod +x /usr/local/bin/helm

Да! Иногда я велосипедю))) Но разве это плохо? xD

Почитав доку с хелмом, нашел их решение по уставновке (ЛОЛка):

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get | bash

Или:

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Можно юзать все кому что удобно.

-=== СПОСОБ 3 ===-

Для Mac OS X имеется установщик через homebrew (Установка homebrew тут):

$ brew install kubernetes-helm kubernetes-cli

Может есть еще другие способы установить данное ПО себе на машину, но думаю этих хватит.

Настройка Helm в Unix/Linux

Для хелма нужно следующее:

• Кластер с кубернетисом (иногда я его буду называть — куб или кубик). Для последней версии Helm рекомендуется использовать последнюю стабильную версию Kubernetes.
• Настройка политик безопасности для кластера и работы с хелмом.
• Вы также должны иметь локальную конфигурацию kubectl.
• Установка и настройка Helm and Tiller (со стороны кластера).

ПРИМЕЧАНИЕ. Kubernetes до 1.6 версии имеет ограниченный или не поддерживаются для управления доступом на основе ролей (RBAC).

Чтобы узнать, какой Tiller кластер будет установлен, вы можете запустить:

$ kubectl config current-context
gke_terraform-2018_us-east1-b_test-cc-stage

Или, можно выполнить:

$ kubectl cluster-info
Kubernetes master is running at https://104.196.128.119

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Unable to connect to the server: x509: certificate signed by unknown authority

Если вы используете Helm в кластере который вы полностью контролируете, например, minikube или кластер в частной сети, в которой совместное использование не вызывает беспокойства, установка по умолчанию, которая не использует конфигурацию безопасности, является нормальной, и это определенно самый простой способ стартануть. Чтобы установить Helm без дополнительных шагов безопасности, установите Helm и затем инициализируйте его.

Однако, если ваш кластер подвергается воздействию более крупной сети или если вы шарите  k8s с другими ( я за ПРОД кластеры) вы должны предпринять дополнительные шаги для защиты вашей установки, чтобы предотвратить компрометирование кластера или его данных.

Если в вашем кластере включен контроль доступа на основе ролей (RBAC), вы можете настроить учетную запись службы и правила до того как приступите юзать хелм.

Чтобы получить некоторую информацию о физических узлах в кластере, выполните:

$ kubectl get nodes

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   1d    v1.10.0

Т.к у меня  это первое знакомство и по этому я не буду приводить примеры по защите k8s кластера. Но когда это понадобится (получу больше опыта) — обязательно дополню статью навыми полезностями.

Инициализация Helm и установка Tiller

Как только вы установили Helm, можете инициализировать его CLI (командную строку), а также установить Tiller в кластер Kubernetes:

$ helm init

Вывод:

Creating /Users/captain/.helm
Creating /Users/captain/.helm/repository
Creating /Users/captain/.helm/repository/cache
Creating /Users/captain/.helm/repository/local
Creating /Users/captain/.helm/plugins
Creating /Users/captain/.helm/starters
Creating /Users/captain/.helm/cache/archive
Creating /Users/captain/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /Users/captain/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

PS: Можно инициализировать Helm следующим образом:

$ helm init --output json

По умолчанию helm init обеспечит настройку локального $HELM_HOME, а затем установит Tiller на кластере. Можно отказатся от установки Tiller, для этого используйте:

$ helm init --client-only

Можно использовать не стабильную версию ПО, для этого есть «—canary-image» опция:

$ helm init --canary-image

Канари не рекомендуется использовать т.к он сырой и не стабильный. Чтобы обновить хелм, используйте:

$ helm init --upgrade

По умолчанию helm сохраняет информацию о release в ConfigMaps пространстве имен (т.е там где он запущен). Начиная с Helm версии 2.7.0, теперь есть бета-версия бета-памяти, которая использует Secrets для хранения информации. Это было добавлено для дополнительной защиты в Kubernetes.

Чтобы включить Secrets бэкэнд, вам необходимо запустить Tiller со следующими параметрами:

$ helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'

Данная команда установит Tiller в кластер Kubernetes, который вы видели с помощью:

$ kubectl config current-context

Можно получить все контенты:

$ kubectl config get-contexts
CURRENT   NAME                                          CLUSTER                                       AUTHINFO                                      NAMESPACE
          docker-for-desktop                            docker-for-desktop-cluster                    docker-for-desktop
          gke_terraform-2018_us-east1-b_test-cc-stage   gke_terraform-2018_us-east1-b_test-cc-stage   gke_terraform-2018_us-east1-b_test-cc-stage
*         minikube                                      minikube                                      minikube

Как видно с вывода, у меня юзается миникуб и он активный в данный момент.

Советы:

• СОВЕТ 1. Хотите установить в другой кластер? Используйте флаг «—kube-context».
• СОВЕТ 2. Если вы хотите обновить Tiller, просто запустите «helm init —upgrade».

По умолчанию Tiller устанавливается в кластер контекста kubectl (kubectl config current-context), в пространство имён kube-system, но это можно изменить, используя соответствующие опции и переменные окружения — они описаны в справке (helm init —help).

$ kubectl get all --selector=name=tiller --namespace kube-system

NAME                                 READY   STATUS    RESTARTS   AGE
pod/tiller-deploy-6fd8d857bc-snfsf   1/1     Running   4          1d

NAME                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
service/tiller-deploy   ClusterIP   10.100.44.210   <none>        44134/TCP   1d

NAME                            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/tiller-deploy   1         1         1            1           1d

NAME                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/tiller-deploy-6fd8d857bc   1         1         1       1d

Можно вывести инфу только для tiller-а:

$ kubectl --namespace kube-system get pods | grep tiller

tiller-deploy-6fd8d857bc-snfsf          1/1     Running   4          1d

Для помощи всегда есть:

$ helm -h
The Kubernetes package manager

To begin working with Helm, run the 'helm init' command:

	$ helm init

This will install Tiller to your running Kubernetes cluster.
It will also set up any necessary local configuration.

Common actions from this point include:

- helm search:    search for charts
- helm fetch:     download a chart to your local directory to view
- helm install:   upload the chart to Kubernetes
- helm list:      list releases of charts

Environment:
  $HELM_HOME          set an alternative location for Helm files. By default, these are stored in ~/.helm
  $HELM_HOST          set an alternative Tiller host. The format is host:port
  $HELM_NO_PLUGINS    disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins.
  $TILLER_NAMESPACE   set an alternative Tiller namespace (default "kube-system")
  $KUBECONFIG         set an alternative Kubernetes configuration file (default "~/.kube/config")
  $HELM_TLS_CA_CERT   path to TLS CA certificate used to verify the Helm client and Tiller server certificates (default "$HELM_HOME/ca.pem")
  $HELM_TLS_CERT      path to TLS client certificate file for authenticating to Tiller (default "$HELM_HOME/cert.pem")
  $HELM_TLS_KEY       path to TLS client key file for authenticating to Tiller (default "$HELM_HOME/key.pem")
  $HELM_TLS_VERIFY    enable TLS connection between Helm and Tiller and verify Tiller server certificate (default "false")
  $HELM_TLS_ENABLE    enable TLS connection between Helm and Tiller (default "false")

Usage:
  helm [command]

Available Commands:
  completion  Generate autocompletions script for the specified shell (bash or zsh)
  create      create a new chart with the given name
  delete      given a release name, delete the release from Kubernetes
  dependency  manage a chart's dependencies
  fetch       download a chart from a repository and (optionally) unpack it in local directory
  get         download a named release
  help        Help about any command
  history     fetch release history
  home        displays the location of HELM_HOME
  init        initialize Helm on both client and server
  inspect     inspect a chart
  install     install a chart archive
  lint        examines a chart for possible issues
  list        list releases
  package     package a chart directory into a chart archive
  plugin      add, list, or remove Helm plugins
  repo        add, list, remove, update, and index chart repositories
  reset       uninstalls Tiller from a cluster
  rollback    roll back a release to a previous revision
  search      search for a keyword in charts
  serve       start a local http web server
  status      displays the status of the named release
  template    locally render templates
  test        test a release
  upgrade     upgrade a release
  verify      verify that a chart at the given path has been signed and is valid
  version     print the client/server version information

Flags:
      --debug                           enable verbose output
  -h, --help                            help for helm
      --home string                     location of your Helm config. Overrides $HELM_HOME (default "/Users/captain/.helm")
      --host string                     address of Tiller. Overrides $HELM_HOST
      --kube-context string             name of the kubeconfig context to use
      --kubeconfig string               absolute path to the kubeconfig file to use
      --tiller-connection-timeout int   the duration (in seconds) Helm will wait to establish a connection to tiller (default 300)
      --tiller-namespace string         namespace of Tiller (default "kube-system")

Use "helm [command] --help" for more information about a command.

Перейдем к использованию.

Использование SSL/TLS между Helm и Tiller

Первое что делаем, — это создаем центр сертификации:

$ openssl genrsa -out ./ca.key.pem 4096
Generating RSA private key, 4096 bit long modulus
.......................................++
.............................................................................++
e is 65537 (0x10001)

И потом запускаем:

$ openssl req -key ca.key.pem -new -x509 -days 7300 -sha256 -out ca.cert.pem -extensions v3_ca
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:Ukraine
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Tiller
Email Address []:solo.metal@bigmir.net

Идем дальше, генерируем ключ для Tiller:

$ openssl genrsa -out ./tiller.key.pem 4096
Generating RSA private key, 4096 bit long modulus
.......................................++
.......................++
e is 65537 (0x10001)

Идем дальше, генерируем ключ для Helm:

$ openssl genrsa -out ./helm.key.pem 4096
Generating RSA private key, 4096 bit long modulus
..................++
............................................................................++
e is 65537 (0x10001)

Затем нам нужно создать сертификаты из этих ключей:

$ openssl req -key tiller.key.pem -new -sha256 -out tiller.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:Ukraine
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Tiller-server
Email Address []:solo.metal@bigmir.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

PS: Я пароль не устанавливал для ключа. Не вижу смысла, т.к настраиваю для тестового окружения.

И мы повторяем этот шаг для Helm сертификата:

$ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:Ukraine
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Helm
Email Address []:solo.metal@bigmir.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Теперь мы подписываем каждую из этих CSR с созданным CA-сертификатом (скорректируйте параметр days в соответствии с вашими требованиями):

$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365
Signature ok
subject=/C=UA/ST=Ukraine/L=Kiev/O=linux-notes/CN=Tiller-server/emailAddress=solo.metal@bigmir.net
Getting CA Private Key

И снова для клиентского сертификата:

$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in helm.csr.pem -out helm.cert.pem  -days 365
Signature ok
subject=/C=UA/ST=Ukraine/L=Kiev/O=linux-notes/CN=Helm/emailAddress=solo.metal@bigmir.net
Getting CA Private Key

На данный момент важными для нас являются следующие файлы:

• CA. Убедитесь, что ключ хранится в секрете: ca.cert.pem и ca.key.pem.
• Файлы Helm клиента: helm.cert.pem и helm.key.pem
• Файлы Tiller сервера: tiller.cert.pem и tiller.key.pem

Т.е структура всех файлов имеет вид:

$ ll
total 72
-rwxrwxrwx  1 captain  staff  2065 Nov  6 10:40 ca.cert.pem
-rwxrwxrwx  1 captain  staff  3247 Nov  6 10:38 ca.key.pem
-rwxrwxrwx  1 captain  staff    17 Nov  6 10:46 ca.srl
-rwxrwxrwx  1 captain  staff  1948 Nov  6 10:46 helm.cert.pem
-rwxrwxrwx  1 captain  staff  1720 Nov  6 10:45 helm.csr.pem
-rwxrwxrwx  1 captain  staff  3243 Nov  6 10:41 helm.key.pem
-rwxrwxrwx  1 captain  staff  1960 Nov  6 10:45 tiller.cert.pem
-rwxrwxrwx  1 captain  staff  1736 Nov  6 10:43 tiller.csr.pem
-rwxrwxrwx  1 captain  staff  3243 Nov  6 10:41 tiller.key.pem

После того как все сгенерировано, можно запустить тиллер:

$ helm init --tiller-tls \
--tiller-tls-cert ./tiller.cert.pem \
--tiller-tls-key ./tiller.key.pem \
--tiller-tls-verify \
--tls-ca-cert ca.cert.pem \
--dry-run \
--debug

Через минуту или две он должен быть готов. Мы можем проверить Тиллера следующим образом:

$ kubectl -n kube-system get deployment

NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
... other stuff
tiller-deploy   1         1         1            1           2m

Если появилась какая-то проблема, вы можете использовать следующую команду для траблшутинга:

$ kubectl get pods -n kube-system

На этом этапе вы должны получить ошибку при запуске основных команд Helm:

$ helm ls
Error: transport is closing

Это связано с тем, что ваш Helm клиент не имеет правильного сертификата для аутентификации в Tiller. Tiller теперь работает с TLS. Пришло время настроить Helm клиент для работы с TLS. Выполним проверку:

$ helm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem

Эта конфигурация отправляет наш клиентский сертификат для установления личности, использует ключ клиента для шифрования и использует CA сертификат для проверки идентификатора удаленного Tiller.

Данная команда, — рабочая, но очень длинная. Чтобы пофиксить все это дело, выполняем:

$ cp ca.cert.pem $(helm home)/ca.pem
$ cp helm.cert.pem $(helm home)/cert.pem
$ cp helm.key.pem $(helm home)/key.pem

После чего, можно смело юзать:

$ helm ls --tls

Как-то так!

Деплой или разворачивания char-тов в Helm

У Helm есть несколько способов установить chart-ы:

1. Найти готовое решение (готовый чарт) и установить его.
2. Создать свой chart и потом задеплоить его.

Если это стандартные решения, без каких-либо изменений, проще всего использовать одну из официальных стабильных диаграмм.

Получаем/обновляем репозиторий со всеми диаграмами(чартами):

$ helm repo update

Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:

$ helm repo list

NAME  	URL
stable	https://kubernetes-charts.storage.googleapis.com
local 	http://127.0.0.1:8879/charts

Ну что, давайте развернем что-то, я не знаю что, но можно поискать:

$ helm search grafana

NAME          	CHART VERSION	APP VERSION	DESCRIPTION
stable/grafana	1.17.4       	5.3.2      	The leading tool for querying and visualizing time series...

Ах да, для вывода всех актуальных чартов можно использовать:

$ helm search

Добавить репозиторий с каким-то чартом (пример incubator репозиторий):

$ helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/

"incubator" has been added to your repositories

И теперь можно поискать\поставить пакет.

PS: Для удаления репозитория можно выполнить:

$ helm repo remove incubator

Перед тем как устанавливать чарт, можно узнать о нем информацию, а сделать это можно выполнив:

$ helm inspect stable/grafana

Если хотите, то перед началом установки chart-а, можно посмотреть какие переменные имеются и потом, при необходимости изменить их:

$ helm inspect values stable/grafana

Установка пакета будет следующим образом:

$ helm install --name=grafana stable/grafana

NAME:   grafana
LAST DEPLOYED: Sat Nov  3 21:23:59 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ClusterRole
NAME                 AGE
grafana-clusterrole  1s

==> v1/Service
grafana  1s

==> v1beta2/Deployment
grafana  1s

==> v1/Pod(related)

NAME                      READY  STATUS             RESTARTS  AGE
grafana-5688858b6c-s9vq2  0/1    ContainerCreating  0         1s

==> v1beta1/PodSecurityPolicy

NAME     AGE
grafana  1s

==> v1/Secret
grafana  1s

==> v1/ClusterRoleBinding
grafana-clusterrolebinding  1s

==> v1beta1/Role
grafana  1s

==> v1beta1/RoleBinding
grafana  1s

==> v1/ConfigMap
grafana  1s

==> v1/ServiceAccount
grafana  1s


NOTES:
1. Get your 'admin' user password by running:

   kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

2. The Grafana server can be accessed via port 80 on the following DNS name from within your cluster:

   grafana.default.svc.cluster.local

   Get the Grafana URL to visit by running these commands in the same shell:

     export POD_NAME=$(kubectl get pods --namespace default -l "app=grafana,component=" -o jsonpath="{.items[0].metadata.name}")
     kubectl --namespace default port-forward $POD_NAME 3000

3. Login with the password from step 1 and the username: admin
#################################################################################
######   WARNING: Persistence is disabled!!! You will lose your data when   #####
######            the Grafana pod is terminated.                            #####
#################################################################################

ЗАМЕЧАНИЕ! С вывода что выше, указаны некоторые инструкции, но у меня не заработал форвардинг портов (пришлось гуглить).

Графана запущена в ПОД-е и доступна только в нем, но чтобы она заработала, нужно выполнить форвординг портов:

$ export POD_NAME=$(kubectl get pods --namespace default -l "app=grafana" -o jsonpath="{.items[0].metadata.name}")

Для удобства, я заекспортил большую команду в переменную и сейчас выполняю форвард портов:

$ kubectl --namespace default port-forward $POD_NAME 3000

Доступ к графане будет на 127.0.0.1:3000. Логин у нас — admin, а вот пароль получаем:

$ kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

Теперь можете пробовать залогинится и проверить как оно работает. Такой запуск имеет свои недостатки, — после выключения ПОД-а, данные с графана-сервера пропадут. Я пока не гуглил как я могу это исправить, но попозже обязательно найду и добавлю в эту статью! Если кто-то знает как это сделать — просьба описать процесс.

Посмотрим какие сервисы уже установились в системе:

$ minikube service list

|-------------|----------------------|--------------|
|  NAMESPACE  |         NAME         |     URL      |
|-------------|----------------------|--------------|
| default     | grafana              | No node port |
| default     | kubernetes           | No node port |
| kube-system | kube-dns             | No node port |
| kube-system | kubernetes-dashboard | No node port |
| kube-system | tiller-deploy        | No node port |
|-------------|----------------------|--------------|

Смотрим релизы:

$ helm list

NAME   	REVISION	UPDATED                 	STATUS  	CHART         	APP VERSION	NAMESPACE
grafana	1       	Sat Nov  3 21:23:59 2018	DEPLOYED	grafana-1.17.4	5.3.2      	default

Чтобы посмотреть ваши ревизии, заюзайте:

$ helm history grafana

REVISION	UPDATED                 	STATUS  	CHART         	DESCRIPTION
1       	Sat Nov  3 21:23:59 2018	DEPLOYED	grafana-1.17.4	Install complete

У меня только одна ревизия релиза т.к я ничего больше не передеплоивал.

Можно выполнить ролбек (откат к какому-то релизу):

$ helm rollback grafana 1

Rollback was a success! Happy Helming!

В хелме ведется история, ее можно просмотерть:

$ helm history grafana

REVISION	UPDATED                 	STATUS    	CHART         	DESCRIPTION
1       	Sat Nov  3 21:23:59 2018	SUPERSEDED	grafana-1.17.4	Install complete
2       	Sat Nov  3 23:28:31 2018	DEPLOYED  	grafana-1.17.4	Rollback to 1

Давайте заскейлим графану до 3- репликаций:

$ kubectl scale --replicas 3 deployment/grafana

deployment.extensions/grafana scaled

Получаем поды:

$ kubectl get pods

NAME                       READY   STATUS    RESTARTS   AGE
grafana-5688858b6c-btxjv   1/1     Running   0          25s
grafana-5688858b6c-d99kb   1/1     Running   0          2m
grafana-5688858b6c-g46fz   1/1     Running   0          25s

Чтобы проверить работает ли скейлинг подов, можно удалить какй-то под и посмотреть что будет:

$ kubectl delete pod grafana-5688858b6c-btxjv
pod "grafana-5688858b6c-btxjv" deleted

Чекаем:

$ kubectl get pods

NAME                       READY   STATUS    RESTARTS   AGE
grafana-5688858b6c-cz4gx   1/1     Running   0          6s
grafana-5688858b6c-d99kb   1/1     Running   0          3m
grafana-5688858b6c-g46fz   1/1     Running   0          1m

С вывода видно что поды вернулись в нужно состояние (т.к я установил репликацию в 3).

Можем получить задеплоиный сервис:

$ kubectl get service

Удалить можно следующим образом:

$ kubectl delete service grafana

Можно получить много полезной информации через:

$ kubectl describe svc grafana

Name:              grafana
Namespace:         default
Labels:            app=grafana
                   chart=grafana-1.17.4
                   heritage=Tiller
                   release=grafana
Annotations:       <none>
Selector:          app=grafana,release=grafana
Type:              ClusterIP
IP:                10.105.2.247
Port:              service  80/TCP
TargetPort:        3000/TCP
Endpoints:         172.17.0.6:3000,172.17.0.7:3000,172.17.0.8:3000
Session Affinity:  None
Events:            <none>

Для удаления релиза можно использовать следующую команду:

$ helm delete grafana

release "grafana" deleted

Для полного удаления релиза используется опция —purge:

$ helm delete --purge grafana

Это я примеры приводил для работы с готовыми chart-ами, которые находятся в репозиторие(ях). Пришло время создать что-то свое. Возможно велосипед, а возможно и произведение искуства =D.

Создание своего chart-а для Helm

И так, создам папку для работы со всеми локальными чартами, например, назову ее:

$ mkdir -p ~/Projects/k8s

Собственно в данной папке будут лежать все мои созданные chart-endpoint-ы.

Создадим каркас для одного из них (где endpoints — это имя вашего чарта):

$ helm create endpoints

Это создаст настройку для Helm Chart, которую вам нужно будет отредактировать:

• $ vim endpoints/templates/deployment.yaml
• $ vim endpoints/templates/service.yaml

Теперь можно установить созданную диаграмму на Kubernetes кластер. Допустим, у вас есть Helm Chart (я назвал его endpoints), мы можем установить ее в наш активный кластер Kubernetes с помощью следующей команды:

$ helm install --name endpoints endpoints

Данное действие установит чарт на k8s кластер с нужными параметрами которые описали в настройках (значения по умолчанию). Что делать, если мы хотим изменить одно значение в файле values.yaml? Мы можем легко это сделать с помощью «—set»команды:

$ helm install --name endpoints endpoints \
--set your_key=your_value

Вот так вот. Вот почему вы вставляете все свои переменные в values.yaml файл. Если вы хотите посмотреть результат до его установки, чтобы убедиться что все выглядит  хорошо, то выполните следующую команду:

$ helm install --name endpoints endpoints \
--set your_key=your_value \
--dry-run \
--debug

Когда вы создадите и отладите ваш чарт, то можно его будет запаковать:

$ helm package endpoints
Successfully packaged chart and saved it to: /Users/captain/Projects/k8s/endpoints-0.1.0.tgz

После создания пакета, можно выполнить установку:

$ helm install ./endpoints-0.1.0.tgz

Вот так вот можно создавать свои чарты.

Установка плагинов в Helm

Для helm-а имеется плагины которые расширяют его функционал. Поставить плагин можно следующим образом:

$ helm plugin install https://github.com/technosophos/helm-template

Установщик позволяет устанавливать плагины и с локальной папки или заархирвированного архива по УРЛу или локальной папке.

Можно писать свои плагины, но если знаешь GO. У меня пока нет времени на его изучение, хотя и хочу!

Работа с Role-based Access Control в Helm

Пока не было возможности поюзать. Дополню как прийдет время.

Автодополнение команд в Helm

Я нашел команду которая генерирует функции для SH/BASH оболочек. Я придумал следующее решение:

$ helm completion bash >> ~/.bash_helm

После чего, открываем файл:

$ vim ~/.bashrc

И пропишем:

if [ -f $HOME/.bash_helm ]; then
    . $HOME/.bash_helm
fi

Сохраняем и перечитаем файл:

$ . ~/.bashrc

Можно выполнить следующую команду для добавления комплитера в ваш ENV:

$ source <(helm completion bash)

PS:  Для миникуба имеется похожее решение!

Больше полезностей будет после того, как я найду что-то полезное. Вот и все, статья «Установка Helm в Unix/Linux» завершена.

Работа с логами (Logs) в Docker

Логи в докере нужны в первую очередь для траблшутинга тех или иных проблем которые возникают у вас в ходе работы с контейнером.

Надеюсь что у вас уже имеется докер на хостевой машине, если нет, вот полезные статьи:

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Установка docker-compose в Unix/Linux

Запуск docker контейнеров в Unix/Linux

Установка docker machine в Unix/Linux

Настройка docker swarm кластера в Unix/Linux

Запуск GUI-приложения в Docker

Запустить bash/SSH в контейнере с Docker

Создание base image для docker в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

Работа с сетью (Networking) в Docker

Работа с томами (Volumes) в Docker

И так, приступим.

Работа с логами (Logs) в Docker

-=== СПОСОБ 1 ===-

Стандартное использование будет следующим:

$ docker logs $(docker ps -aql)

Version:    v0.4.9
Git commit: c4de4ad0
OS/Arch:    linux/amd64
Built:      Wed Aug 29 12:32:14 2018
time="2018-10-31T10:58:45Z" level=info msg="Controller ready"

Или если задали контейнер_нейм:

$ docker logs vault

-=== СПОСОБ 2 ===-

Логи монтируются на хостевую машину, по этому гегко понять где лежат логи:

$ docker inspect vault | grep -E "LogPath"
        "LogPath": "/var/lib/docker/containers/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b-json.log",

И после чего, выполняем:

$ cat /var/lib/docker/containers/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b-json.log

-=== СПОСОБ 3 ===-

Иногда бывает так, что приложенько не умеет выводить логи. Рассмотрим наглядный пример. Запустим контейнер:#

$ docker run -d -P myhttpd:latest
791c65b5aed05a11a40a953779675b5b94d090e691730c5c0bceaa33143fcbc4

Пробуем поулчить логи:

$ docker logs $(docker ps -lq)
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.17. Set the 'ServerName' directive globally to suppress this message

Как видно с вывода, докер не может считать логи с контейнера. Первое что приходит в голову, — это не рабочий контейнер, да? Но пробуем получить данные:

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
my httpd container

Этим самым, видно что контейнер работает, но все еще не может отдавать логи.

Делов в том, что логи для Nginx лежат:

$ docker run nginx ls -l /var/log/nginx
total 0
lrwxrwxrwx 1 root root 11 Oct 2 19:20   access.log  -> /dev/stdout     
lrwxrwxrwx 1 root root 11 Oct 2 19:20   error.log -> /dev/stderr

# docker run httpd cat conf/httpd.conf | egrep '^ *(Error|Custom)Log'
ErrorLog /proc/self/fd/2
   CustomLog /proc/self/fd/1 common

FROM centos
LABEL maintainer="Vitaliy Natarov"
RUN yum install -y httpd web-assets-httpd && yum clean all
RUN echo "logs are sending to stdout" > /var/www/html/index.html

RUN ln -s /dev/stdout /var/log/httpd/access_log && \ 
    ln -s /dev/stderr /var/log/httpd/error_log

EXPOSE 80 
CMD httpd -DFOREGROUND

$ docker build -t myhttpd:2.0 .

$ docker run -d -P myhttpd:2.0
1b0c3a82d0687519ffcd2ee06d345a4d3ad8d475dc0d7710fb279bdd836e5e88

$ docker logs $(docker ps -lq)

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.17. Set the 'ServerName' directive globally to suppress this message

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
logs are sending to stdout

$ docker logs $(docker ps -lq)
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using
172.17.0.18. Set the 'ServerName' directive globally to suppress this message
172.17.0.1 - - [29/Jul/2018:22:07:24 +0000] "GET / HTTP/1.1" 200 19 "-" "curl/7.29.0"

Настройка  Log Driver

Запустим контейнер с заданным именем и лог-драйвером, например:

$ docker run -d -P --name=myhttpd --log-driver=journald myhttpd:2.0 
5748f3078b647c43a335bdc1f8bc7c8d9db31a491e635effd58b31b1429c8ee7

Проверим что вышло:

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
logs are sending to stdout

Получите log-и контейнера через journald ( с указанием CONTAINER_NAME), например:

# journalctl -b CONTAINER_NAME=myhttpd
-- Logs begin at Sat 2018-07-28 19:14:07 BST, end at Sun 2018-07-29 23:19:52 BST. --
Jul 29 23:19:29 localhost.localdomain 5748f3078b64[2806]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.
Jul 29 23:19:50 localhost.localdomain 5748f3078b64[2806]: 172.17.0.1 - - [29/Jul/2018:22:19:50 +0000] "GET / HTTP/1.1" 200 19 "-" "curl/7.29.0"

Запускаем кнтейнер с log-driver-ом и log-tag-ом:

$ docker run -d -P --log-driver=journald \
--log-opt tag=myhttpd \
myhttpd:latest
0555d7a41ab6af098dfea296e2fa7b4f1c6b73424e2156c387930b13bfcefb24

Чекаем:

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
   logs are sending to stdout

С такой командой, теперь можно получить логи через указанный тег:

$ journalctl -b CONTAINER_TAG=myhttpd

Поддерживаемые Log Driver-ы:

• none — Логи не доступны для контейнера, и логи самого докера не возвращают никакого вывода.
• json-file- Log-и отформатированы как JSON. Данный драйвер используется по умолчанию в Docker.
• syslog — Записывает логи в syslog. Демон syslog должен быть запущен на самом хосте.
• journald — Записывает логи в journald. Демон journald должен быть запущен на самом хосте.
• gelf — Записывает сообщения в Graylog (GELF) или Logstash.
• fluentd — Записывает сообщения на fluentd (forward input). Демон fluentd должен быть запущен на самом хосте.
• awslogs- Записывает сообщения в Amazon CloudWatch.
• splunk — Записывает сообщения в splunk с помощью сборщика HTTP событий (HTTP Event Collector).
• gcplogs — Записывает сообщения в Google Cloud Platform (GCP).
• logentries — Записывает сообщения в Rapid7 Logentries.

Проверим что используется поумолчанию:

$ docker info --format '{{.LoggingDriver}}'
json-file

Меняем на нужный:

# cat << EOF > /etc/docker/daemon.json {
"log-driver": "journald" }
EOF

Перезапустим сервисы:

# systemctl daemon-reload && systemctl restart docker.service

Проверяем, изменилось ли у нас что-то:

$ docker info --format '{{.LoggingDriver}}'
journald

Можно запустить контейнер:

$ docker run -d -P --name=myweb --log-opt tag=myweb_tag myhttpd:2.0

Проверим логи одним из способов:

$ journalctl -b CONTAINER_NAME=myweb
$ journalctl -b CONTAINER_TAG=myweb_tag

Вот и все, статья «Работа с логами (Logs) в Docker» завершена.

Работа с томами (Volumes) в Docker

Volumes — являются механизмом для сохранения данных, создаваемых и используемых Docker контейнерами (с хостевой машины на контейнер).

Надеюсь что у вас уже имеется докер на хостевой машине, если нет, вот полезные статьи:

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Установка docker-compose в Unix/Linux

Запуск docker контейнеров в Unix/Linux

Установка docker machine в Unix/Linux

Настройка docker swarm кластера в Unix/Linux

Запуск GUI-приложения в Docker

Запустить bash/SSH в контейнере с Docker

Создание base image для docker в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

Работа с сетью (Networking) в Docker

И так, приступим.

Работа с томами (Volumes) в Docker

Сейчас буду приводить наглядные примеры того, каким образом можно работать с волюмами, стореджами.

Создание Volumes в Docker

Чтобы создать Volume, выполните:

$ docker volume create --name http-custom-data
http-custom-data

Проверим что имеется в докере:

$ docker volume ls

Или вывести только необходимый:

$ docker volume ls | grep http-custom-data
local http-custom-data

Получим подробную инфу:

$ docker volume inspect http-custom-data

my custom page from Volume

$ cp index.html /var/lib/docker/volumes/http-custom-data/_data/

$ ls -l /var/lib/docker/volumes/http-custom-data/_data/
total 4
-rw-r--r-- 1 root root 28 Oct 11 20:40 index.html

$ docker run -d -P -v http-custom-data:/usr/share/nginx/html nginx 
b94feb29c143eea7900965706447151e96df86539312bdcea79b42952bae701a

$ docker port $(docker ps -lq)

80/tcp -> 0.0.0.0:32769

# curl 127.0.0.1:32769
my custom page from Volume

$ docker volume create --driver local \ --opt type=tmpfs \
--opt device=tmpfs \
--opt o=size=100m,uid=1000 \
foo

$ docker volume create \
--driver local \ 
--opt type=btrfs \
--opt device=/dev/sda2 \
foo

$ docker volume create \
--driver local \ 
--opt type=nfs \
--opt o=addr=192.168.1.1,rw \
--opt device=:/path/to/dir \
foo

Монтирование Volumes  с хостевой машины в контейнер.

Добавление Volum-ов  в контейнер(ы)  являются хорошим решением т.к при завершении жизни контейнера все ваши данные будут утеряны. Если ваш контейнер генерирует непостоянные данные, рассмотрите возможность использования монтирования tmpfs, чтобы избежать постоянного хранения данных в любом месте и увеличить производительность контейнера, избегая записи на перезаписываемый слой контейнера.

Рассмотрим пример:

$ docker run -d -p 127.0.0.1:8080:80 -v $(pwd):/var/www/html:ro httpd

Или вот еще примеры:

$ docker run --rm -v $(pwd):$(pwd) -w $(pwd) maven:3.3-jdk-8 clean package
$ docker run -d -v /var/log/httpd:/var/log/httpd httpd
$ docker run -d -v /var/log/tomcat:/usr/local/tomcat/logs tomcat
$ docker run -d -v /data:/etc/mongo mongo

Монтирование tmpfs является временным и сохраняется только в памяти хоста. Когда контейнер остановится, монтирование tmpfs будет удалено, и файлы, написанные там, не будут сохранены.

Ограничения монтирования tmpfs:

• Вы не можете шарить данные монтированием tmpfs между контейнерами.
• Эта функция доступна только в том случае, если вы используете Docker в Linux.

Пример запуска:

$ docker run -d -ti -p127.0.0.1:8282:8200 --name=vault_test --mount type=tmpfs,destination=/tmp vault:0.11.4

Выглядит это так:

Case #1. VOLUME в Dockerfile

Создадим докерфайл выглядит:

FROM nginx
RUN echo "default page" > /usr/share/nginx/html/index.html VOLUME /usr/share/nginx/html/

Соберем:

$ docker build -t nginx_v:1 .
...
Successfully built efdfe29e01fd Successfully tagged nginx_v:1

$ docker run -d -p80:80 nginx_v:1
$ curl localhost
default page

$ docker exec $(docker ps -lq) \
sh -c 'echo changed page > /usr/share/nginx/html/index.html'
$ curl localhost
changed page

$ docker stop $(docker ps -lq)

$ docker inspect $(docker ps -lqa) | jq '.[]|.Mounts'
[
{
"Type": "volume",
"Name": "395c2b4639c0a577ff25b379adc201e77a1cedbc5d50e91150149e1f51191182",
"Destination": "/usr/share/nginx/html", "Driver": "local",
"Mode": "",
"RW": true,
"Source": "/
var/lib/docker/volumes/395c2b4639c0...f51191182/_data",
"Propagation": "" }
]

$ cat /var/lib/docker/volumes/395c2b4639c0a577ff25b379adc201e77a1cedbc5d50e91150149e1f51191182/_data/index.html

changed page

$ docker rm $(docker ps -lqa)

$ cat /var/lib/docker/volumes/395c2b4639c0a577ff25b379adc201e77a1cedbc5d50e91150149e1f51191182/_data/index.html

changed page

$docker run -d -p 80:80 -v /usr/share/nginx/html nginx
$ curl localhost
...
<title>Welcome to nginx!</title>
...

$ docker inspect $(docker ps -lqa) | jq -r '.[]|.Mounts[] | .Source'
/var/lib/docker/volumes/b6400a50ad0a0e8f11fa962cb99e7d2e425ac1654c4e4ea1376ae61a05e5dbc8/_data

$ echo changed > $(docker inspect $(docker ps -lqa) | jq -r '.[]|.Mounts[] | .Source')/index.html
$ curl localhost
changed

$ docker run -d -v /usr/share/nginx/html --name c1 nginx
$ echo changed > $(docker inspect c1 | jq -r '.[]|.Mounts[] | .Source')/index.html

$ docker run --volumes-from c1 busybox cat /usr/share/nginx/html/index.html
changed

Изменить storage driver для docker в Linux

Проверим что имеется:

$ docker info | egrep "(Cgroup|Storage) Driver"
Storage Driver: overlay2
Cgroup Driver: cgroupfs

Можно выполнить настройку:

$ cat << EOF > /etc/docker/daemon.json {
"exec-opts": [ "native.cgroupdriver=systemd"
],
"storage-driver": "devicemapper" }
EOF

# systemctl daemon-reload
# systemctl restart docker.service

# docker info | egrep "(Cgroup|Storage) Driver" 
Storage Driver: devicemapper
Cgroup Driver: systemd

Изменить storage driver для docker в Mac OS X

Проверим что имеется:

$ docker info | egrep "(Cgroup|Storage) Driver"
Storage Driver: overlay2
Cgroup Driver: cgroupfs

Я использую docker edge  и по этому, приведу наглядный пример того, как можно поменять сторедж. Запускаем docker, переходим в «Preferences»:

Переходим во вкладку «Daemon». И во вкладке «Advanced» прописываем нужный сторедж, например:

После добавляения:

{
  "debug" : true,
  "storage-driver" : "overlay2",
  "experimental" : true
}

Жмакаем на «Apply & Restart». Ждем пока докер перезапустится и можно проверить что вышло:

$ docker info | grep -E "Storage Driver"
Storage Driver: overlay2

Как видно с вывода — все работает.

У меня все, статья «Работа с томами (Volumes) в Docker» завершена.

Работа с сетью (Networking) в Docker

Я довольно давно работаю с docker,  не все время, а переодически, но тем-не-менее я проникся докер технологией. Порой не было времени освоить\ познать глубины докера и написать статью для заметок. Сейчас много чего изменилось, у меня появилось желание и время, по этому — я могу рассказать о «Работа с сетью (Networking) в Docker».

Надеюсь что у вас уже имеется докер на хостевой машине, если нет, вот полезные статьи:

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Установка docker-compose в Unix/Linux

Запуск docker контейнеров в Unix/Linux

Установка docker machine в Unix/Linux

Настройка docker swarm кластера в Unix/Linux

Запуск GUI-приложения в Docker

Запустить bash/SSH в контейнере с Docker

Создание base image для docker в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

И так, приступим.

Работа с сетью (Networking) в Docker

Сетевая Docker подсистема подключается используя драйверы. По умолчанию существует несколько драйверов которые обеспечивают основные сетевые функции:

• bridge: Мост, — это сетевой драйвер по умолчанию. Бридж сеть используется, когда ваши приложения запускаются в автономных контейнерах, которые должны взаимодействовать между собой (Наглядный пример Nginx + MySQL).
• host:  Хост, — это сетевой драйвер для автономных контейнеров (удаленная сетевая изоляция между контейнером и Docker хостом). Данный драйвер доступен только для docker-swarm с поддержкой Docker 17.06 и выше.
• overlay/overlay2: Оверлей (Наложенная сеть), — это сетевой драйвер для соединения несколько демонов Docker между собой и которые позволяют  docker-swarm службам взаимодействовать друг с другом. Вы также можете использовать оверлейные сети для облегчения связи между docker-swarm и автономным контейнером или между двумя отдельными контейнерами на разных Docker демонах. Эта стратегия устраняет необходимость выполнения маршрутизации на уровне ОС между этими контейнерами.
• macvlan: Маквлан,- это сетевой драйвер, который позволяют назначать MAC-адрес контейнеру, делая его отображаемым как физическое устройство в вашей сети. Docker демон направляет трафик на контейнеры по их MAC-адресам. Использование macvlan драйвера иногда является лучшим выбором при работе с устаревшими приложениями, которые ожидают, что они будут напрямую подключены к физической сети.
• none: Нон,- это сетевой драйвер, который умеет отключать всю сеть для контейнеров. Обычно используется в сочетании с пользовательским сетевым драйвером.
• Network plugins: Вы можете установить и использовать сторонние сетевые плагины с Docker контейнерами. Эти плагины доступны в Docker Store или у сторонних поставщиков услуг.

Где и что лучше использовать?

• Мост (bridge) лучше всего использовать для связи  нескольких контейнеров на одном и том же Docker хосте. Можно юзать docker-compose и выберать даную сеть для такой связки.
• Хост (host) сети лучше всего юзать, когда сетевой стек не должен быть изолирован от хоста Docker, но вы хотите, чтобы другие аспекты контейнера были изолированы.
• Овердейная сеть (overlay/overlay2) или наложение сетей лучше всего заюзать, когда вам нужны контейнеры, работающие на разных Docker хостах для связи, или, когда несколько приложений работают вместе, используя docker-swarm.
• Маквлан (macvlan) сети лучше всего использовать, когда вы переходите с VM/дедикейта  на контейнеры или хотите, чтобы ваши контейнеры выглядели как физические хосты в вашей сети, каждый с уникальным MAC-адресом.
• Сторонние сетевые плагины позволяют интегрировать Docker со специализированными сетевыми стеками.

Просмотреть Network в Docker

Чтобы проверить какие сети имеются, выполните следующую команду:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
6df045e07b11        bridge              bridge              local
9d45c14e604a        host                host                local
b285e48f2c94        none                null                local

Где:

• NETWORK ID —  При создании сети, ей присваивается ID. Так это собственно индификатор сети.
• NAME — Имя сети. Можно задать произвольное имя.
• DRIVER — Используемый драйвер для созданной сети.
• SCOPE — Где используется.

Если посмотреть на поле «DRIVER»,  то можно понять что я использую стандартную сеть, которую предоставляет сам докер.

Создать Network в Docker

Давайте создадим сеть, самый простой способ это:

$ docker network create bridge-network

c8668b3fc7f6ac9d8694a34d225327f9abb1d195c9757966919ed4adf9b35cea

Или:

$ docker network create --driver=bridge bridge-network

Вы можете создавать bridge, overlay, host, none или кастомный network-инг. По дефолту, — создается мост. Проверяем что вышло:

$ docker network ls

NETWORK ID          NAME                DRIVER              SCOPE
6df045e07b11        bridge              bridge              local
9d45c14e604a        host                host                local
c8668b3fc7f6        bridge-network      bridge              local
b285e48f2c94        none                null                local

Как я и говорил, создался бридж с указанным названием сети. Давайте рассмотрим пример создания оверлей-сети:

$ docker network create -d overlay my-multihost-network

Или:

$ docker network create --driver overlay overlay_network

Можно создать macvlan сеть, например:

$ docker network create -d macvlan \
 >   --subnet=172.16.86.0/24 \
 >   --gateway=172.16.86.1 \
 >   -o parent=eth0 \
 >   my-macvlan-net
7ca5727963f953b669da216ddaf42143df54efb31464fa8b46eda9edefa45000

Еще один пример создания сети:

$ docker network create --subnet 10.1.0.0/16 --gateway=10.1.0.1 --ip-range 10.1.4.0/24 --driver=bridge --label=host4networks brifge04
233fa875d361ac26951c0e62d4c406b36e90835eea3a2fba4186df987b3037c9

Проверим созданную сеть на примере, какого-то контейнера:

$ docker run -it --name=test_brifge04 --net brifge04 centos:centos7 /bin/bash

PS: Если нужно, то контейнеру можно выделить статик ИП:

$ docker run -it --name=test_brifge04_2 --net brifge04 --ip=10.1.4.100 centos:centos7 /bin/bash

При создании сети, можно задавать дополнительные параметры, с ними можно ознакомится:

$ docker network create --help

Usage:	docker network create [OPTIONS] NETWORK

Create a network

Options:
      --attachable           Enable manual container attachment
      --aux-address map      Auxiliary IPv4 or IPv6 addresses used by Network driver (default map[])
      --config-from string   The network from which copying the configuration
      --config-only          Create a configuration only network
  -d, --driver string        Driver to manage the Network (default "bridge")
      --gateway strings      IPv4 or IPv6 Gateway for the master subnet
      --ingress              Create swarm routing-mesh network
      --internal             Restrict external access to the network
      --ip-range strings     Allocate container ip from a sub-range
      --ipam-driver string   IP Address Management Driver (default "default")
      --ipam-opt map         Set IPAM driver specific options (default map[])
      --ipv6                 Enable IPv6 networking
      --label list           Set metadata on a network
  -o, --opt map              Set driver specific options (default map[])
      --scope string         Control the network's scope
      --subnet strings       Subnet in CIDR format that represents a network segment

Идем дальше.

Подключить/Отключить контейнер(ы) к/от сети в Docker

Чтобы законектить контейнер к сети, нужно выполнить следующую команду:

$ docker network connect YOUR_NETWORK YOUR_CONTAINER

Где:

• YOUR_NETWORK — Сеть.
• YOUR_CONTAINER — Контейнер.

Для отключения служит обратная команда:

$ docker network disconnect YOUR_NETWORK YOUR_CONTAINER

Где:

• YOUR_NETWORK — Сеть.
• YOUR_CONTAINER — Контейнер.

Идем далее.

Инспектор Network в Docker

Можно получить подробную информацию о той или иной сети, например:

$ docker network inspect bridge-network
[
    {
        "Name": "bridge-network",
        "Id": "c8668b3fc7f6ac9d8694a34d225327f9abb1d195c9757966919ed4adf9b35cea",
        "Created": "2018-10-19T08:24:28.511405837Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Довольно много полезной информации можно получить из данной команды.

Так же, можно получить инфу со следующей команды:

$ docker info

Или если есть необходимость в форматировании и выводе нужных полей, то можно заюзать следующий формат:

$ docker info --format 'table {{.Plugins.Volume}} {{.Plugins.Network}}'
table [local] [bridge host ipvlan macvlan null overlay]

Удаление Network в Docker

Для удаления сети, используйте:

$ docker network rm YOUR_NETWORK

Или если нужно удалить все созданные сети которые не используются вами:

$ yes|docker network prune

Если появится хороший материал, обязательно добавлю в данную статью. Вот и все, тема «Работа с сетью (Networking) в Docker» подошла к завершению.

Установка Kubernetes кластера в Unix/Linux

Kubernetes (часто так же используется обозначение «K8s», название образовано от греческого κυβερνήτης, — «кормчий»,»рулевой», по русски — Кубернетес или Кубернетис) — открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Оригинальная версия была разработана компанией Google. Впоследствии Kubernetes был передан под управление Cloud Native Computing Foundation. Предназначение Kubernetes — предоставить «платформу для автоматического развёртывания, масштабирования, управления приложениями на кластерах или отдельных хостах». Кубернетис поддерживает различные технологии контейнеризации, включая Docker, VMWare и ряд других.

Kenernetes используется фондом Wikimedia Foundation, инфраструктура которого мигрировала на это приложение с самостоятельно разработанного ПО для организации кластеров.

Установка Kubernetes кластера в Unix/Linux

Я рассказывал об установке kubernetes-а ранее в моей статье, — Установка Kubernetes в Unix/Linux. По этому — я немного опущу установку ПО и расскажу как можно собрать полноценный кластер с «блэкджеком и куртизанками», т.е — собрать все воедино. Добавлять автоматически ноды, мониторить их и так же — выполнять деплой приложений, скейлинг в зависимости от нужд.

И так дано:

• 192.168.13.219 — Нода kubernetes-master-1 на CentOS 7.
• 192.168.13.230 — Нода kubernetes-worker-1 наDebian 8.
• 192.168.13.147 — Нода kubernetes-worker-2 на Debian 8.

Кластерная диаграмма  кубернетес кластера, выглядит следующим образом:

• Мастер отвечает за управление кластером. Master узлы будут координировать всю деятельность, происходящую в вашем кластере, например, приложения для планирования, сохранение желаемого состояния, масштабирование приложений и обновление апликейщенов.
• Узел (node) представляет собой виртуальную машину или физический компьютер, который используется в качестве рабочего компьютера в кластере Kubernetes. Каждый узел из кластера управляется мастером. На типичном узле вы будете иметь инструменты для обработки операций с контейнерами (например, Docker, rkt) и Kubelet, агента для управления узлом. Кластер Kubernetes, который обрабатывает ПРОД, должен иметь минимум три узла в кластере.

Когда мы развертываем приложения на Kubernetes, мы говорим мастеру, чтобы он запускал контейнеры и планировал их запуск на других нодах. Связь между мстером и воркерами(нодами) осуществляется через API — мастером. Тот же API доступен для пользователей, чтобы облегчить взаимодействие с кластером.

Хватит теории, перейдем к установке и настройке самого кластера!

Установка kubernetes-master-1 на CentOS 7

Установлю хостнейм:

# hostnamectl set-hostname kubernetes-master-1

Это не столь важно, но для примера — будет красиво!

Т.к у меня нет DNS-сервера (я строю кластер локально, на виртуальных машинах), то нужно прописать:

# vim /etc/hosts

Следующее:

192.168.13.219 kubernetes-master-1
192.168.13.233 kubernetes-worker-1
192.168.13.234 kubernetes-worker-2

Это поможет резолвить ноды между собой.

Обновлю ОС:

# yum update -y && yum upgrade -y

Не забываем выключить SELinux,  а то он может наломать вам дров:

# setenforce 0 && sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

Как вы знаете, в centOS 7 имеется firewalld и по этому — стоит пробрасывать правила (но в моем случае — нету смысла) или просто выключить его:

# systemctl stop firewalld && systemctl disable firewalld

Добавим репозиторий с kubernetes:

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

Собственно, выполняем установку докера и кубика:

# yum install docker kubectl kubeadm etcd ebtables ethtool -y

Добавялем докер-службу в автозагрузку ОС и запускаем сервис:

# systemctl enable docker && systemctl restart docker

Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure net.bridge.bridge-nf-call-iptables is set to 1 in your sysctl config, e.g.

# cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

и применяем:

# sysctl --system

Насчет etcd, я не уверен что нужно сувать его в автозагрузку ОС. Но можно это сделать вот так:

# systemctl enable etcd && systemctl restart etcd

Инициализируем мастер:

# kubeadm init --ignore-preflight-errors=all --pod-network-cidr=10.244.0.0/16

Где:

• kubeadm init — Инициализируем кубернетес.
• —ignore-preflight-errors=all — Скипаю все ошибки (но лучше не использовать этот параметр если не уверены).
• —pod-network-cidr=10.244.0.0/16 — Задаем подсеть для будущего кубо-кластера (не обязательная опция).
• —apiserver-advertise-address=192.168.13.231 — Можно задать данный параметр для установки IP адреса самого API сервера (не обязательная опция).
• —kubernetes-version $(kubeadm version -o short) — Чтобы задать версию кубика (не обязательная опция).
• —token=YOUR_TOKEN — Используется чтобы задать токен (не обязательная опция).

Добавялем кубернетес-службу в автозагрузку ОС и запускаем сервис:

# systemctl enable kubelet

Я не буду добавлять пользователя для кубика, буду использовать — root. Вносим изменения небольшие:

# mkdir -p $HOME/.kube
# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config

Так же, незабываем сохранить команду для добавления нод в мастер, у меня это:

# kubeadm join --token 86669e.c66ab92be6dc5817 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:f8905cc439b0498eeb3a0de4bf7937640c96cb7063a2bc99f917433a994c4559

Смотрим что вышло:

# kubectl get nodes
NAME                  STATUS     ROLES     AGE       VERSION
kubernetes-master-1   NotReady   master    4m        v1.9.3

PS: Можно получить следующую ошибку:

Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

Решил:

# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && chown $(id -u):$(id -g) $HOME/.kube/config

Как видим, у меня — уже просетапался кубик-мастер нода. Но статус не готов, смотрим что не так:

# kubectl get pods --all-namespaces

NAMESPACE     NAME                                          READY     STATUS    RESTARTS   AGE
kube-system   etcd-kubernetes-master-1                      1/1       Running   0          27m
kube-system   kube-apiserver-kubernetes-master-1            1/1       Running   0          27m
kube-system   kube-controller-manager-kubernetes-master-1   1/1       Running   0          28m
kube-system   kube-dns-6f4fd4bdf-rtkjt                      0/3       Pending   0          28m
kube-system   kube-proxy-vs44m                              1/1       Running   0          28m
kube-system   kube-scheduler-kubernetes-master-1            1/1       Running   0          27m

Такс, нет DNS резолвера, — фиксаем:

# export kubever=$(kubectl version | base64 | tr -d '\n')
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
serviceaccount "weave-net" created
clusterrole "weave-net" created
clusterrolebinding "weave-net" created
daemonset "weave-net" created

Различные сети поддерживаются в k8s и зависят от выбора пользователя. Создание сети, занимает определенное время (пару минут точно), через время — проверяем:

[root@kubernetes-master-1 ~]# kubectl get nodes && kubectl  get pods --all-namespaces
NAME                  STATUS    ROLES     AGE       VERSION
kubernetes-master-1   Ready     master    33m       v1.9.3
NAMESPACE     NAME                                          READY     STATUS              RESTARTS   AGE
kube-system   etcd-kubernetes-master-1                      1/1       Running             0          32m
kube-system   kube-apiserver-kubernetes-master-1            1/1       Running             0          32m
kube-system   kube-controller-manager-kubernetes-master-1   1/1       Running             0          32m
kube-system   kube-dns-6f4fd4bdf-rtkjt                      0/3       ContainerCreating   0          32m
kube-system   kube-proxy-vs44m                              1/1       Running             0          32m
kube-system   kube-scheduler-kubernetes-master-1            1/1       Running             0          32m
kube-system   weave-net-pzpxk                               2/2       Running             0          45s
[root@kubernetes-master-1 ~]#

Идем дальше — необходимо установить и добавить воркеры в созданный мастер!

Установка kubernetes-worker-1 на Debian 8

Установлю хостнейм:

# hostname kubernetes-worker-1

Это не столь важно, но для примера — будет красиво!

Т.к у меня нет DNS-сервера (я строю кластер локально, на виртуальных машинах), то нужно прописать:

# vim /etc/hosts

Следующее:

192.168.13.219 kubernetes-master-1
192.168.13.233 kubernetes-worker-1
192.168.13.234 kubernetes-worker-2

Это поможет резолвить ноды между собой.

Ставим нужные зависимости:

# apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common

Устанавливаем докер:

# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
add-apt-repository \
"deb https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \
$(lsb_release -cs) \
stable"

Этой командой, добавляем репку, и для установки — выполняем:

# apt-get update && apt-get install -y docker-ce=$(apt-cache madison docker-ce | grep 17.03 | head -1 | awk '{print $3}')

Добавляем докер в автозагрузку ОС, запускаем его и смотрим статус:

# systemctl start docker && systemctl enable docker && systemctl status docker

Добавляем ключ:

# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Прописываем репо-лист:

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

Сейчас, ставим кубик:

# apt-get update && apt-get install -y kubelet kubeadm kubectl

Добавляем kubelet в автозагрузку ОС, запускаем его и смотрим статус:

# systemctl start kubelet && systemctl enable kubelet && systemctl status kubelet

Все готово, можно добавлять ноду в кластер:

# kubeadm join --token c4de10.ff1831543e2e223a 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:f75e564824bb87a906a83f11fabc74b31c759a206dae75401448980e64d0953e

Где:

• kubeadm join — Команда для добавления узлов к мастеру.
• —token c4de10.ff1831543e2e223a — Токен для добавления.
• 192.168.13.219:6443 — Хост и порт от мастер-ноды.
• —discovery-token-ca-cert-hash sha256:f75e564824bb87a906a83f11fabc74b31c759a206dae75401448980e64d0953e — Дискавер токен.
• —discovery-token-unsafe-skip-ca-verification — Можно использовать данную опцию для использывания обхода проверки токена обнаружения. Поскольку этот токен генерируется динамически, мы не могли включить его в действия. При создании ПРОД машин, укажите токен, предоставленный kubeadm init.

Получил ошибку:

CGROUPS_MEMORY: missing
	[WARNING FileExisting-crictl]: crictl not found in system path
[preflight] Some fatal errors occurred:
	[ERROR SystemVerification]: missing cgroups: memory
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

Фиксим так, для начала — добавляем:

# echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab

Потом, открываем файл:

# vim /etc/default/grub

Находим строку «GRUB_CMDLINE_LINUX» и приводим к виду:

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

Потом, выполняем:

# update-grub && reboot

Немного о cgroups:

Установка cgroups в Unix/Linux

И потом, можно запускать (добавляем воркер к мастеру):

# kubeadm join --token 86669e.c66ab92be6dc5817 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:f8905cc439b0498eeb3a0de4bf7937640c96cb7063a2bc99f917433a994c4559

На kubernetes-master-1, запускаем:

# kubectl get nodes

Идем дальше — необходимо установить и добавить еще один воркер в созданный мастер!

Установка kubernetes-worker-2 на Debian 8

Аналогичные действия, проделываю и для kubernetes-worker-2. Но только с другим хостнеймом.

Установка kubernetes-worker-n на CenOS 7/Redhat 7

Можно добавлять другие воркеры по аналогии как я описывал ранее для kubernetes-master-1, но без инициализации мастера (что логично, не правдали?).

Деплой Kubernetes кластера в Unix/Linux

Приведу наглядный скриншот того, как выглядит развертывание первого приложения на Kubernetes:

Образ контейнера развертывается, а так же — количество реплик определяются во время создания деплоя, но могут быть изменены после.

Когда все ноды будут добавлены в кластер, должно получится что-то типа:

[root@kubernetes-master-1 ~]# kubectl get nodes
NAME                  STATUS       ROLES     AGE       VERSION
kubernetes-master-1   Ready        master    8m        v1.9.3
kubernetes-worker-1   Ready        <none>    54s       v1.9.3
kubernetes-worker-2   NotReady     <none>    40s       v1.9.3
[root@kubernetes-master-1 ~]#

Как видно что 2-й воркер не успел кодключится еще к кластеру. Через время подключится. Нужно пару минут подождать. Ну, пол работы сделано — осталось научится деплоить, мониторить и может чет еще упустил…

-=== СПОСОБ 1 ===-

Деплоим:

# kubectl create deployment nginx --image=nginx

Смотрим какие деплойменты имеются:

# kubectl get deployments
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     1         1         1            1           41s

Можно получить дополнительную инфу, выполнив:

# kubectl describe deployment nginx

Получаем что-то типа:

Name:                   nginx
Namespace:              default
CreationTimestamp:      Tue, 13 Mar 2018 14:18:29 +0200
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=1
Selector:               app=nginx
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-7d7cbfc4f (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-7d7cbfc4f to 1

Делаем контейнер доступным в интернете:

# kubectl create service nodeport nginx --tcp=80:80

Смотрим статус:

# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        26m
nginx        NodePort    10.103.16.105   <none>        80:32564/TCP   23s

Проверяем работу контейнеров:

# curl kubernetes-worker-1:32564
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cstyle%3E%0A%20%20%20%20body%20%7B%0A%20%20%20%20%20%20%20%20width%3A%2035em%3B%0A%20%20%20%20%20%20%20%20margin%3A%200%20auto%3B%0A%20%20%20%20%20%20%20%20font-family%3A%20Tahoma%2C%20Verdana%2C%20Arial%2C%20sans-serif%3B%0A%20%20%20%20%7D%0A%3C%2Fstyle%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="<style>" title="<style>" />
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

На 2-м воркере:

# curl kubernetes-worker-2:32564

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cstyle%3E%0A%20%20%20%20body%20%7B%0A%20%20%20%20%20%20%20%20width%3A%2035em%3B%0A%20%20%20%20%20%20%20%20margin%3A%200%20auto%3B%0A%20%20%20%20%20%20%20%20font-family%3A%20Tahoma%2C%20Verdana%2C%20Arial%2C%20sans-serif%3B%0A%20%20%20%20%7D%0A%3C%2Fstyle%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="<style>" title="<style>" />
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

На мастере я не запускал воркер, по этому — смысла проверять, — нет.

Можно посмотреть сколько реплик имеется:

[root@kubernetes-master-1 ~]# kubectl get rs

NAME                             DESIRED   CURRENT   READY     AGE
kubernetes-bootcamp-69d869bf78   1         1         1         1d
nginx-7d7cbfc4f                  1         1         1         1d
[root@kubernetes-master-1 ~]#

Чтобы проверить поды, выполняем:

[root@kubernetes-master-1 ~]# kubectl get pods<br>
NAME                                   READY     STATUS    RESTARTS   AGE
kubernetes-bootcamp-69d869bf78-84mvw   1/1       Running   0          1d
nginx-7d7cbfc4f-9s5dd                  1/1       Running   0          1d
[root@kubernetes-master-1 ~]#

Ролбэк Kubernetes кластера в Unix/Linux

Можно выполнять ролбэки:

# kubectl rollout status deployments nginx

Можно проверить хистори всех ролбеков:

[root@kubernetes-master-1 ~]# kubectl rollout history deployment/nginx<br>
deployments "nginx"
REVISION  CHANGE-CAUSE
1         <none>

[root@kubernetes-master-1 ~]#

Теперь я выполню откат к предыдущей версии:

# kubectl rollout undo deployment/nginx

Где:

• —to-revision=2 — С данной опцией, можно задать до какой ревизии делаем откат.

Масштабирование Kubernetes кластера в Unix/Linux

Выполняем масштабирование:

# kubectl scale deployment nginx --replicas=5

deployment "nginx" scaled

Или:

# kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

Проверяем:

# kubectl get deploy

NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1         1         1            1           1d
nginx                 5         5         5            5           1d
[root@kubernetes-master-1 ~]#

Можно выводить много полезной инфы вот так:

# kubectl get deployment,svc,pods,pvc

Все гениальное — просто. Но нужно время чтобы понять.

Мониторинг Kubernetes кластера в Unix/Linux

Дополню когда пойму как можно это сделать автоматически. У меня есть как минимум, 3 способа реализации. Но 1 из них — не очень хорошее решение.

1. Можно заюзать zabbix и просетапать все kubernetes ноды, zabbix-агентами. Это реально будет работать, но как по мне — не ТРУЪ!
2. Можно использовать consul для этого дела — это лучше решение чем заббикс.
3. Так же, можно использовать  prometheus

Но об этом немного позже. Я дополню эту часть, обязательно!

Удаление Kubernetes кластера в Unix/Linux

Чтобы удалить ноду с кластера, на мастере, выполните:

# kubectl delete node your_node_for_delete

Если же нужно удалить вообще все — то обратное действие — установки.

Для удаления деплоймента, используйте:

# kubectl delete deployment nginx

Теоретически, данный кластер можно поднять минут за 10-15. Но я потратил больше времени, — выплывали всякие косяки. Вывод — данная цтилита, довольно прикольная и юзабельная, но как по мне — нужна доработка. Так же, хотелось отметить, что мой кластер работает, но его нужно оптимизировать/автоматизировать. Нужно больше времени чтобы понять как я могу это сделать.

Вот и все, статья «Установка Kubernetes кластера в Unix/Linux» завершена.

Установка Kubernetes в Unix/Linux

Kubernetes — это предназначенный для контейнерной оркестровки фреймворк с открытым исходным кодом. Он был создан с учетом богатейшего опыта Google в области создания сред управления контейнерами и позволяет выполнять контейнеризованные приложения в готовом к промышленной эксплуатации кластере.

Разработанный на тех же принципах, что позволяет Google запускать миллиарды контейнеров в неделю, Kubernetes может масштабироваться без увеличения вашей команды ops.

Независимо от того, тестируете ли вы локально или работает с PROD, гибкость Kubernetes растет с вами, чтобы обеспечить бесперебойную доставку ваших приложений независимо от сложности вашей потребностей.

Kubernetes — предоставляет вам свободу использовать инфраструктуру на местах, гибридную или общественную облачную инфраструктуру, позволяя вам легко перемещать рабочие нагрузки туда, где это важно.

Концепции Kubernetes

• Nodes (node.md): Нода это машина в кластере Kubernetes.
• Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
• Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
• Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
• Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
• Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
• Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.

Архитектура Kubernetes

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.

Архитектура Kubernete

Нода Kubernetes

При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.

Kubelet

Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.

Kube-Proxy

Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.

Компоненты управления Kubernetes

Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.

etcd

Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

Kubernetes API Server

Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).

Scheduler

Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.

Kubernetes Controller Manager Server

Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.

ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.

Сеть в kubernetes

Flannel — сетевой оверлей, который позволит контейнерам связываться через несколько хостов.

Calico — это система с открытым исходным кодом, обеспечивающая взаимодействие с облачными приложениями и политикой.

Canal — это инициатива, основанная на сообществах, которая позволяет пользователям легко развертывать сети Calico и flannel вместе (как единое сетевое решение), сочетающее в себе ведущие в отрасли сетевые политики Calico с богатым набором опций Calico и фланцевого наложения и опциями без подключения к сети.

Kube-route — построен вокруг концепции наблюдателей и контроллеров. Наблюдатели используют API-интерфейс Kubernetes для получения уведомлений о событиях, связанных с созданием, обновлением и удалением объектов Kubernetes. Каждый наблюдатель получает уведомление, относящееся к определенному объекту API. При получении события от сервера API наблюдатель передает события. Контроллер регистрируется, чтобы получать обновления от наблюдателей и действовать на события.

Romana — это решение для автоматизации сетей и безопасности для облачных приложений. Romana автоматизирует создание изолированных облачных сетей, защищает приложения, использующие микросегментацию, и применяет политики контроля доступа на всех конечных точках, где бы они ни запускались.

Weave Net — еще одно решение для реализации сети в Kubernetes с поддержкой CNI.

Установка Kubernetes в Unix/Linux

Для работы с кубернетисом, нужен — докер (Ого — нежданчик! Да? ). Начнем с установки docker-а, у меня уже имеется документация по этому можете ознакомится тут:

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Вспомогательная информация, возможно — будет полезна:

Установка docker-compose в Unix/Linux

Создание docker с nginx + lua на CentOS7

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

Ну что, перейдем к установке самого кубирнетиса…

Установка Kubernetes в CenOS/Fedora/RedHat

В настройке Kubernetes у нас есть главный узел (master) и дочерние узлы (minions). Для управления кластером (мастером и миньенами) можно используя команды «kubeadm» и «kubectl».

Kubernetes можно установить и развернуть, используя следующие методы:

• Minikube (это единичный кластер — single node kubernetes cluster).
• Kops (настройка нескольких серверов (Multi node kubernetes) в AWS)
• Kubeadm (кластер Multi Node в наших собственных помещениях)

Для примера, я возьму три сервера ( Пример: CentOS с минимальной установкой). Один сервер будет работать как мастер, а остальные два сервера — будут миньонами или рабочими узлами. Диаграмма будет такая:

На главном узле (он же мастер) будут установлены следующие компоненты:

• API Server, Scheduler, Controller Manager, etcd, Kubectl utility — Описание данных сервисов/служб, я описывал выше.

На рабочих узлах (они же миньйоны) будут установлены следующие компоненты:

• Kubelet, Kube-Proxy, Pod — Описание данных сервисов/служб, я описывал выше.

Установка и настройка kubernetes master ноды в CentOS

Начем с того, что выключим SELinux — у меня есть статья Как отключить SELinux на CentOS но для выстроты, я все таки напишу команды:

# setenforce 0 && sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

Так же, если используете фаервол, то стоит пробросить порты (пример для CentOS 7):

 # firewall-cmd --permanent --add-port=6443/tcp
 # firewall-cmd --permanent --add-port=2379-2380/tcp
 # firewall-cmd --permanent --add-port=10250/tcp
 # firewall-cmd --permanent --add-port=10251/tcp
 # firewall-cmd --permanent --add-port=10252/tcp
 # firewall-cmd --permanent --add-port=10255/tcp
 # firewall-cmd --reload
 # modprobe br_netfilter
 # echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

PS: Можно выключить службу:

# systemctl stop firewalld.service

ИЛИ:

$ systemctl stop firewalld && systemctl disable firewalld

Так же, я хотел бы отметить то, что кубик не поддерживает SWAP. По этому, его можно проигнорировать или выключить вообще (swapoff -a).

Не забываем о том, что если вы не юзаете DNS сервер, то стоит прописать /etc/hosts файл все ваши хосты, например:

# bash -c 'cat <> /etc/hosts
192.168.13.10 master
192.168.13.20 node-1
192.168.13.30 node-2
EOF'

Скачаем утилиту kubectl (на момент написания статьи, использовалась самая новая версия ПО):

# curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

Перенесем файл:

$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl

Добавим репозиторий с kubernetes:

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

Собственно, выполняем установку:

# yum install ebtables ethtool kubeadm etcd kubectl -y

Вы должны убедиться, что net.bridge.bridge-nf-call-iptables установлен в 1 в вашей конфигурации sysctl, например:

# cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

и применяем:

# sysctl --system

Добавялем службу в автозагрузку ОС и запускаем сервис:

# systemctl enable kubelet && systemctl restart kubelet

Так же, стоит запустить докер!

На какой-то ноде получил ошибку:

Mar  2 13:02:31 localhost systemd: kubelet.service holdoff time over, scheduling restart.
Mar  2 13:02:31 localhost systemd: Started kubelet: The Kubernetes Node Agent.
Mar  2 13:02:31 localhost systemd: Starting kubelet: The Kubernetes Node Agent...
Mar  2 13:02:31 localhost kubelet: I0302 13:02:31.294420    1907 feature_gate.go:226] feature gates: &{{} map[]}
Mar  2 13:02:31 localhost kubelet: I0302 13:02:31.294496    1907 controller.go:114] kubelet config controller: starting controller
Mar  2 13:02:31 localhost kubelet: I0302 13:02:31.294500    1907 controller.go:118] kubelet config controller: validating combination of defaults and flags
Mar  2 13:02:31 localhost kubelet: error: unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory
Mar  2 13:02:31 localhost systemd: kubelet.service: main process exited, code=exited, status=1/FAILURE
Mar  2 13:02:31 localhost systemd: Unit kubelet.service entered failed state.
Mar  2 13:02:31 localhost systemd: kubelet.service failed.

Решение:

# kubeadm reset && systemctl restart kubelet && kubeadm init --skip-preflight-checks --pod-network-cidr=10.244.0.0/16

Собственно, можно пропустить данный фикс. Оно исправится с инициализацией кластера…..

Запустите команду чтобы инициализировать и настроить kubernetes мастер ноду:

# kubeadm init

Примерный вывод:

[init] Using Kubernetes version: v1.9.3
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks.
	[WARNING FileExisting-crictl]: crictl not found in system path
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [localhost.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.13.219]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests".
[init] This might take a minute or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 49.503153 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[markmaster] Will mark node localhost.localdomain as master by adding a label and a taint
[markmaster] Master localhost.localdomain tainted and labelled with key/value: node-role.kubernetes.io/master=""
[bootstraptoken] Using token: b8e1bf.c8828a7e32947b5e
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: kube-dns
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token b8e1bf.c8828a7e32947b5e 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:2b17b03e16e2a0459abdd05b191abf8c444b264b2f4fe28d44ae2ff6ab7b1837

Внизу имеется токен, он нам понадобится немного позже (когда будем добавлять ноды в кластер). Сохраните его! Если забыли или упустили токен, можно посмотреть токены:

# kubeadm token list
TOKEN                     TTL       EXPIRES                     USAGES                   DESCRIPTION                                                EXTRA GROUPS
c732da.2ee47aa3370b4460   23h       2018-03-03T13:03:19+02:00   authentication,signing   The default bootstrap token generated by 'kubeadm init'.   system:bootstrappers:kubeadm:default-node-token

Для генерации токена, можно использовать:

# kubeadm token generate
2d4041.f36eaef929570488

Для использования сгенерированного токена, служит команда:

# kubeadm token create 2d4041.f36eaef929570488 --print-join-command --ttl=0

Удаляем токен так:

# kubeadm token delete 2d4041.f36eaef929570488

bootstrap token with id "2d4041" deleted

Чтобы сбросить все настройки, используйте:

# kubeadm reset

PS: Так же, можно использовать:

$ sudo kubeadm init --apiserver-advertise-address=192.168.13.10 --pod-network-cidr=10.244.0.0/16

Где:

• —apiserver-advertise-address=192.168.13.10  — явно указывает мастеру на IP адрес, который нужно сообщать клиентам для подключения
• —pod-network-cidr=10.244.0.0/16 используется для установки адресного пространства для ваших pod-ов в flannel.

Сейчас стоит выполнить настройку для запуска кластера от определенного пользователя:

# mkdir -p $HOME/.kube && cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && chown $(id -u):$(id -g) $HOME/.kube/config

PS: У меня это будет пользователь — root. Но для удобства использования, можно создать отдельного юзера, например — kubernetes и выставить права на него:

# adduser kubernetes
# passwd kubernetes
# usermod -aG wheel kubernetes
# su - kubernetes

Сейчас, нужно настроить pod network для кластера:

# kubectl get nodes

С самого начала, — сеть будет не доступна. Выполним еще проверку:

# kubectl get pods --all-namespaces

Чтобы статус кластера был готов (Было все настроено и так же, имел kube-dns status — running , разверните сеть контейнера, чтобы контейнеры разных хостов обменивались друг с другом. Сеть POD представляет собой оверлейную сеть между рабочими узлами. Запустите команду для развертывания сети:

# export kubever=$(kubectl version | base64 | tr -d '\n')
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
serviceaccount "weave-net" created
clusterrole "weave-net" created
clusterrolebinding "weave-net" created
daemonset "weave-net" created

Различные сети поддерживаются в k8s и зависят от выбора пользователя. Хочу привести еще один пример с сетью, который использует RBAC (Role Based Access Control), поэтому убедитесь, что сеть, которую вы собираетесь использовать, поддерживает RBAC (не проверял работу этого сетевого интерфейса):

# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Думаю что уже все будет работать, но стоит перепроверить это еще 1 раз:

# kubectl get nodes && kubectl  get pods --all-namespaces

Чтобы получить больше полезной информации, выполните:

$ kubectl get pods –all-namespaces -o wide

Поздравляю, — мастер готов!

Установка и настройка kubernetes миньйонов в CentOS

Начем с того, что выключим SELinux — у меня есть статья Как отключить SELinux на CentOS но для выстроты, я все таки напишу команды:

# setenforce 0 && sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

Так же, если используете фаервол, то стоит пробросить порты (пример для CentOS 7):

# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd --permanent --add-port=30000-32767/tcp
# firewall-cmd --permanent --add-port=6783/tcp
# firewall-cmd  --reload
# echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

Не забываем о том, что если вы не юзаете DNS сервер, то стоит прописать /etc/hosts файл все ваши хосты.

Добавим репозиторий:

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

Собственно, выполняем установку (на всех воркерах или миньйонах):

# yum install ebtables ethtool kubeadm -y

PS: Добавляем докер в автозагрузку ОС и запускаем его!

Добавляем миньйоны в kubernetis kluster (мастер):

# kubeadm join --token KUBERNETES_MASTER_TOKEN KUBERNETES_MASTER_IP:6443

Где:

• KUBERNETES_MASTER_TOKEN — Это токен, который служит для добавления рабочих нод в кластер.
• KUBERNETES_MASTER_IP — Это IP самого кубернетес мастер ноды.
• 6443 — Порт от мастер-ноды.

Для проверки работоспообности созданного кластера, выполним:

# kubectl get nodes

Для автодополнения команд, можно выполнить следующее:

$ echo "source <(kubectl completion bash)" >> ~/.bashrc

Как-то так!

Установка Kubernetes в Debian/Ubuntu

-=== СПОСОБ 1 ===-

Ставим зависимости:

# apt-get install gcc golang-go curl git apt-transport-https ebtables ethtool

Устанавливаем ETCD:

# curl -L https://github.com/coreos/etcd/releases/download/v2.0.3/etcd-v2.0.3-linux-amd64.tar.gz -o etcd-v2.0.3-linux-amd64.tar.gz && tar xzvf etcd-v2.0.3-linux-amd64.tar.gz && cd etcd-v2.0.3-linux-amd64

Копируем бинарник:

# cp etcd /usr/bin/etcd

Ставим права:

# chmod +x /usr/bin/etcd

Скачиваем и компилируем сам кубик:

# cd /usr/local/src && git clone https://github.com/GoogleCloudPlatform/kubernetes.git
# cd kubernetes && make release

В папке с кубернетесом появятся скрипты для работы с кластером, нодами. Например:

#  hack/local-up-cluster.sh

Для автодополнения команд, можно выполнить следующее:

$ echo "source <(kubectl completion bash)" >> ~/.bashrc

Как-то так!

-=== СПОСОБ 2 ===-

Нужно обновить ОС, и установить вспомогательные пакеты:

# apt-get update && apt-get install -y apt-transport-https ebtables ethtool

Первый шаг — загрузить и добавить ключ для установки Kubernetes:

# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add

Открываем файл:

# vim  /etc/apt/sources.list.d/kubernetes.list

Прописываем в него:

deb http://apt.kubernetes.io/ kubernetes-xenial main

Сохраняем и закрываем файл. Выполняем установку Kubernetes:

# apt-get update && apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Установка и настройка kubernetes мастера в Debian/Ubuntu

На мастер ноде, выполняем инициализацию кластера:

# kubeadm init

Прежде чем присоединить ноды в кластер, необходимо выпустить следующие команды (как обычный пользователь или при необходимости, создать нового юзверя):

# mkdir -p $HOME/.kube
# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config

Кластер уже инициализирован, нужно развернуть сеть:

# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-rbac.yml

Проверим работоспособность клатера (до того как начнем добавлять ноды в кластер):

# kubectl get pods —all-namespaces

Установка и настройка kubernetes миньйонов в Debian/Ubuntu

Точно так же, ставим кубик… после чего, выполняем добавление нод:

# kubeadm join --token KUBERNETES_MASTER_TOKEN KUBERNETES_MASTER_IP:6443

Где:

• KUBERNETES_MASTER_TOKEN — Это токен, который служит для добавления рабочих нод в кластер.
• KUBERNETES_MASTER_IP — Это IP самого кубернетес мастер ноды.
• 6443 — Порт от мастер-ноды.

На мастере, выполняем команду:

# kubectl get nodes

Более понятно было описано в пункте с установкой kubernetes-а для CentOS.

Для автодополнения команд, можно выполнить следующее:

$ echo "source <(kubectl completion bash)" >> ~/.bashrc

Как-то так!

Установка Kubernetes в Mac OS X

Существует пару способов установить кубик на MacOS X.

-=== СПОСОБ 1 — Использовать Docker Edge ===-

Скачиваем Docker Edge образ с официального сайта, нужно установить его (куда же без этого). Запускаем. Во вкладке «kubernetes» нужно включить данную функцию:

Нажимаем на «Enable Kubernetes» и потом на «Install». Это запустит кластер Kubernetes для одного узла и установит kubectl утилиту. Это может занять некоторое время….

Через несколько минут, я вижу что у меня кубик запустился «Kubernetes is running» и можно приступить к использованию. Прежде чем продолжить: если вы ранее использовали kubectl, вам, возможно, придется переключить контекст на локальный кластер (local cluster). Выполните следующую команду:

# kubectl config use-context docker-for-desktop

Получаем вывод:

Switched to context "docker-for-desktop".

Нет смысла запускать кластер с kubernetes, если вы не будете с ним работать, не так ли? Начнем с того, что развернем пользовательский интерфейс панели управления Kubernetes, для этого стоит выполнить:

# kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

secret "kubernetes-dashboard-certs" created
serviceaccount "kubernetes-dashboard" created
role "kubernetes-dashboard-minimal" created
rolebinding "kubernetes-dashboard-minimal" created
deployment "kubernetes-dashboard" created
service "kubernetes-dashboard" created

Еще, потребуется запустить прокси:

# kubectl proxy

После этого, открываем:

http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy

И, попадаем в меню первоначальной настройки. Я не стал ничего применять — нажал на «skip» чтобы пропустить. И собственно зашел в админ панель:

Что это за панель я еще и сам не понял. Но работает!

-=== СПОСОБ 2 — Использовать Homebrew ===-

Как оказалось потом, kubernetes можно установить и через brew. Для начала, стоит установить homebrew.

Выполняем установку Xyve Driver:

$ brew install docker-machine-driver-xhyve
# chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
# chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

Выполняем установку Minikube:

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
# chmod +x minikube
# mv minikube /usr/local/bin/

Выполняем установку Kubectl:

$ brew install kubectl

Наконец, пришло время запустить Кубернетес. Ниже приведены две команды для запуска Minikube. Выполните следующую команду, чтобы проверить, имеете ли вы доступ к сайтам за прокси-сервером или нет:

$ curl --proxy "" https://cloud.google.com/container-registry/

No Proxy: Если вы не находитесь за прокси-сервером, выполните следующую команду:

$ minikube start --vm-driver=xhyve

Proxy: Выполните следующую команду, когда вы находитесь за прокси-сервером:

$ minikube start --vm-driver=xhyve --docker-env HTTP_PROXY=http://your-http-proxy-host:your-http-proxy-port  --docker-env HTTPS_PROXY=http(s)://your-https-proxy-host:your-https-proxy-port

Для запуска minikube используйте:

$ minikube start

Для остановки minikube используйте:

$ minikube stop

Выполните следующую команду для доступа к панели управления Kubernetes:

$ minikube dashboard

Открываем ссылку:

http://127.0.0.1:30000/#!/overview?namespace=default

Для автодополнения команд, можно выполнить следующее:

## If running Bash 3.2 included with macOS
$ brew install bash-completion
## or, if running Bash 4.1+
$ brew install bash-completion@2

Как-то так!

Использование Kubernetes в Unix/Linux

Ну что, готовы задеплоить службу на своем Kubernetes кластере? Возьму пример с nginx:

# kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
# kubectl expose deployment nginx-app --port=80 --name=nginx-http

Если вы перейдете на ноду и выполните команду:

# docker ps -a

То вы увидите, что указанная служба запустилась на кластере. Я пока что не буду заострять внимание на деплое приложенек, все будет, но не сразу.  В новой теме, я расскажу как развернуть полноценный kubernetes кластер с «блэкджеком и куртизанками».

Возможно я не затронул какие-то моменты, но я на данную статью потратил довольно много времени. Если появится что дополнить, обязательно добавлю. При желании, любой желающий может помогать мне в этом.

Вот и все, статья «Установка Kubernetes в Unix/Linux» подошла к завершению.

Использование статического IP адреса в docker-compose

Docker – очень крутое решение для создание отдельных контейнеров для каждого из приложений.

Docker-compose —  это утилита для работы с docker контейнерами, которая позволит вам построить лучшую оркестровку с ними (например иметь статический IP-адрес в контейнере(ах) ). Но в данной статье «Использование статического IP адреса в docker-compose» речь пойдет о том как создавать статические IP для контейнера(ов).

Почитав документацию, я нашел следующее решение:

networks:
  bridge:
    driver: bridge
    ipam:
     config:
       - subnet: 172.10.0.0/16
         gateway: 172.10.5.254
         aux_addresses:
          nginx: 172.10.1.2
          php: 172.10.1.3      
          db: 172.10.1.4

И это позволяет мне указать статические адреса для моих контейнеров с помощью docker-compose.yaml файла.

Вот мой полный пример этого файла:

version: "2"
services:
  nginx:
    image: nginx:latest
    environment: 
      NGINX_SERVER_NAME: docker_machine.local   
    container_name: lemp_nginx
    restart: always
    links:
      - php
    volumes:
      - ./DATA/html:/var/www/html/:ro
      - ./DATA/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./DATA/nginx/conf.d:/etc/nginx/conf.d:ro
    ports:
      - 80:80
      - 443:443
    networks:
      - bridge
  php:
    image: php:latest
    container_name: lemp_php
    restart: always
    volumes:
      #- ./DATA/php-fpm/site.conf:/usr/local/etc/php-fpm.d:ro 
      - ./DATA/html:/var/www/html
    depends_on:
      - db
    links:
      - db
    networks:
      - bridge
    environment:
      - DB_NAME=lemp_magento
      - TABLE_PREFIX=lemp_
      - DB_HOST=lemp
      - DB_PASSWORD=magento
      - PHP_HOST_NAME=localhost:9000
  db:
    image: mariadb:latest
    container_name: lemp_mariadb
    restart: always
    volumes:
      #- ./DATA/mariadb/my.cnf:/etc/mysql/my.cnf:ro  
      - db-data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root666PW
    networks:
      - bridge
volumes:
  db-data:
    driver: local

networks:
  bridge:
    driver: bridge
    ipam:
     config:
       - subnet: 172.10.1.0/16
         gateway: 172.10.1.1
         aux_addresses:
           nginx: 172.10.1.10
           php: 172.10.1.20      
           db: 172.10.1.30

Покажу еще один пример использования:

version: '2'

services:
  app:
    image: busybox
    command: ping linux-notes.org
    networks:
      app_net:
        ipv4_address: 10.0.0.10
  webapp:
    image: busybox
    command: ping www.linux-notes.org
    network_mode: service:app
        

networks:
  app_net:
    driver: bridge
    ipam:
      driver: default
      config:
      - subnet: 10.0.0.0/24
        gateway: 10.0.0.1

Можно создать бридж и вручную, а об этом я расскажу ниже.

Создать новой Docker Bridge Network

Посмотрим имеющиеся сети:

# docker network ls

Вывод:

┌(vagrant@vagrant-ansible)─(✗)─(03:46 pm Sun Feb 05)
└─(~/magento2)─(5 files, 8.0Kb)─> sudo docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
fdbe53a6094b        bridge              bridge              local
75f532ba432e        host                host                local
b704f856d986        none                null                local

┌(vagrant@vagrant-ansible)─(✓)─(03:47 pm Sun Feb 05)
└─(~/magento2)─(5 files, 8.0Kb)─> 

Докер создает три сети для каждого хоста автоматически:

1. bridge — Сеть по умолчаянию для подключения контейнеров — это docker0  сеть (network)  во всех docker установках.
2. none — Container-specific networking stack
3. host — Добавляет контейнер на hosts networking стек. Сетевая конфигурация идентична хосту.

Создаем новую сеть (network) для нашего докера:

# docker network create -d bridge NetWork

aa5d365b8a6efae6d6f704e17565f1db890e96f47356e4931a9bab80d972d6cd

Где, NetWork — это название сети.

Еще раз смотрим список сетей:

$ sudo docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
aa5d365b8a6e        NetWork             bridge              local
fdbe53a6094b        bridge              bridge              local
75f532ba432e        host                host                local
b704f856d986        none                null                local

Как видно с вывода, NetWork — создалась и ее можно использовать. В моем случае это — bridge ( мост).

Проверяем созданную сеть с помощью:

$ sudo docker network inspect NetWork

И, получаем вывод:

[
    {
        "Name": "NetWork",
        "Id": "aa5d365b8a6efae6d6f704e17565f1db890e96f47356e4931a9bab80d972d6cd",
        "Created": "2017-02-05T15:58:34.705436228Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.21.0.0/16",
                    "Gateway": "172.21.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Как можно было увидеть из моего вывода, что ни один контейнер не назначен для этой сети. Я описывал как это сделать. Но под руку попался еще один пример, я сейчас расскажу о нем.

Открываем:

# vim docker-compose.yml

Прописываем:

version: "2"
services:
  nginx:
    image: nginx:latest
    container_name: nginx
    restart: always
    volumes:
      - ./DATA/html:/var/www/html/:ro
      - ./DATA/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./DATA/nginx/conf.d:/etc/nginx/conf.d:ro
    ports:
      - 80:80
      - 443:443
    networks: ${NETWORK}

И чтобы запустить, выполняем:

NETWORK=NetWork docker-compose up -d

Вот и все, тема «Использование статического IP адреса в docker-compose» завершена.

Запустить bash/SSH в контейнере с Docker

Подключится к контейнеру с Docker тема не новая, но я бы хотел создать заметку на будущее. По этому, поехали….

Запустить ssh внутри контейнера можно несколькими способами.

-=== СПОСОБ 1 — Использование имени docker контейнера ===-

Выполняем команду:

$ docker run -t -i centos7/nginx_lua /bin/bash

Где:

• centos7/nginx_lua — Название docker контейнера.
• /bin/bash — Shell оболочка для запуска.

-=== СПОСОБ 2 — Использование ID самого docker контейнера ===-

Выполняем команду:

# docker exec -i -t 6kk7790fdfs76 bash

Где:

• 6kk7790fdfs76 — ID-шник  самого docker контейнера.
• /bin/bash — Shell оболочка для запуска.

Вот и все, статья «Запустить bash/SSH в контейнере с Docker» завершена.