Админим с Буквой
5.52K subscribers
303 photos
8 videos
59 files
1.16K links
Канал о системном администрировании, DevOps и немного Инфобеза.

По всем вопросам обращаться к @bykva. Рекламу не размещаю.
Download Telegram
helm upgrade... the fucking resource already exists

хелм на данный момент все еще сырой продукт. И ведет он себя довольно-таки странно в некоторых ситуациях. При добавлении нового ресурса можно получить ошибку... что ресурс, мать его, не найден! Мало того что ресурс не найден, так если запросить kubectl, оказалось что helm все прекрасно создал!

как workaround мне повезло решить проблему так:
1) разделить все ресурсы по отдельным yaml'ам (я добавил новый ресурс - ingress+secrets два в одном)
2) удалить все эти ресурсы, на которые ругается helm
3) запустить upgrade заново и надеяться что вам повезет.

Мне - повезло, а вы?

#troubleshooting #helm #kubernetes #fucking_fuck
Jenkins heartbeat error

err:
wrapper script does not seem to be touching the log file in xxxxx
(JENKINS-48300: if on a laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=300)


В моем случае jenkins находится в k8s, катал его с помощью helm. В качестве решения в values.yaml:

Master:
JavaOpts: "-Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600"


#jenkins #kubernetes #helm #troubleshooting
Обновляем Gitlab 10.8 -> 11.x установленный через helm

нужно изменить переменную git_data_dir в templates/configmap.yaml на следующее:

git_data_dirs['default']['path'] = '/gitlab-data/git-data';

Ошибка:

Chef Client finished, 274/445 resources updated in 04 minutes 26 seconds

Deprecations:

Your git_data_dir settings are deprecated.
Please update it to the following:

git_data_dirs({
"default" => {
"path" => "/gitlab-data/git-data"
}
})

Please refer to https://docs.gitlab.com/omnibus/settings/configuration.html#storing-git-data-in-an-alternative-directory for updated documentation.

#helm #kubernetes #gitlab
helm 2.10 released!

Для тех кто им пользуется постоянно наверное это не новость, но для меня, как человека почти 3 недели гонявшего в отпуска это таки новость=)

changelog: https://github.com/helm/helm/releases/tag/v2.10.0

#helm
заставляем git использовать указанный ssh ключ при деплое чужого контейнера в k8s

Решал задачу по внедрению поисковика по коду: https://github.com/etsy/hound.

Hound is an extremely fast source code search engine. The core is based on this article (and code) from Russ Cox: Regular Expression Matching with a Trigram Index. 


В рамках этой задачи было принято решение написать helm пакет для уже готового docker на docker hub. Сам helm можно потыкать здесь: https://github.com/bykvaadm/hound-helm-chart

Отдельно в этой заметке хотел бы отметить небольшую проблему, решаемую в рамках задачи: научить hound ходить в приватные репозитории по указанному приватному ключу. При этом не хотелось ни модифицировать контейнер автора, ни делать persistent volume, ни какой либо init-контейнер.

Способов заставить git ходить с указанным ключом довольно много, но большинство из них подразумевает что вы правите какой-то конфиг или модифицируете строку запуска git. Ни того ни другого делать в чужом контенере не хотелось. В итоге как один из наиболее простых способов был взят вариант с использованием wrapper. wrapper - это скрипт, который будет вызван git'ом при запуске ssh, вместо запуска ssh. Таким образом внутри wrapper можно писать любую логику, подставляя в зависимости от ситуации нужные параметры. на выходо wrapper должен заменять собой вызов ssh с какими-то параметрами. В моем случае так сложно делать не надо и wrapper скрипт получился такой:

#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /etc/ssh-key/id_rsa $@


Здесь я указываю чтобы не чекался fingerprint и путь к конкретному ключу. В итоге для helm пишется configmap и secret. один кладет wrapper, а другой - приватный ключ.

Теперь все что остается - задать в deployment переменную окружения GIT_SSH, в которой указать путь к wrapper.

#git #helm #kubernetes
Helm - how to call helper functions in a loop

Several of the Go templating constructs change the meaning of . to be the thing that's being looped over, and you need to use $ to refer to the initial value. Most of your template correctly refers to e.g. $.Release.Name, but when you invoke the helper template, it's using the current context rather than the root value.

i.e. put this

chart: {{ template "myapp-on-kube.chart" $ }}

instead of this:
chart: {{ template "myapp-on-kube.chart" . }}


#helm
Удобная конструкция для установки хелма ансиблом

  - name: install helm
unarchive:
src: https://storage.googleapis.com/kubernetes-helm/helm-{{ helm_version }}-linux-amd64.tar.gz
dest: /usr/local/bin
remote_src: yes
extra_opts:
- --strip-components=1
- linux-amd64/helm
creates: /usr/local/bin/helm


#helm #ansible
Helm v3 и terraform

Несколько дней назад наконец-то вышел релиз провайдера для терраформа который уже умеет в 3-й хелм. Ура-ура.

https://github.com/terraform-providers/terraform-provider-helm/releases/tag/v1.0.0

#terraform #helm
Собрал стенд для обучения работы с hashicorp vault

Разворачивается через вагрант на локальных вм. Поднимается куб кластер в котором поднимается HA версия vault с бекендом на HA etcd.

НА - это не на, а аббревиатура. написано большими буквами потому что я не помню как пишется high availabilпыр-пыр-пыр. etcd используется вместо консула потому что почему бы и нет. разница в бэкенде не существенна при обучении работы с vault. (ну на самом деле, потому что консул в кубе можно развернуть только один кластер, а это значит что мы отдаем его только под секреты - ведь не шарить же его еще с кем-то если мы там храним секреты, а в данном случае кажется избыточным поднимать консул, ведь если у вас будет 20 нод, вы получите 20 реплик консула (так написан чарт), а у etcd по-прежнему останется 3. )

В данном репозитории ТОЛЬКО сам стенд. материалы для обучения продаются, как говорится, отдельно =)

https://github.com/bykvaadm/vault-on-kubernetes-stand

#virtualbox
#vagrant
#ansible
#kubernetes
#helm
#docker
#etcd
#ingress
#hashicorp
#vault
#обучение

З.Ы. поделились аналогичным стендом, на компоузах и с консулом. https://github.com/temalovepizza/vaultstuff
Собираем helm-чарт в gitlab-ci и пушим в docker registry

Используем экспериментальную фичу с oci-registry в которую научился хелм. Это значит что мы можем чарты теперь просто пушить рядом с контейнерами докера с таким же именованием и тегированием.

deploy_helm:
stage: deploy
image: docker:18-dind
services:
- docker:18-dind
environment: { name: production }
tags: [docker]
only:
refs: [master]
script:
- export CHART_VERSION=$(grep version Chart.yaml | awk '{print $2}')
- chmod 400 $DOCKERCONFIG
- mkdir registry
- alias helm='docker run -v $(pwd)/regisry:/root/.cache/helm/registry -v $(pwd):/apps -v ${DOCKERCONFIG}:/root/.docker/config.json -e DOCKER_CONFIG="/root/.docker" -e HELM_REGISTRY_CONFIG="/root/.docker/config.json" -e HELM_EXPERIMENTAL_OCI=1 alpine/helm'
- helm chart save . registry.company.com/helm/charts/debezium:${CHART_VERSION}
- helm chart push registry.company.com/helm/charts/debezium:${CHART_VERSION}

Структура репозитория - файлы чарта и .gitlab-ci.yml. После запуска деплоя создается воркер - докер с поддержкой docker-in-docker. Мы качаем публичный контейнер хелма на альпине. Все пробросы нужны для того чтобы хелм внутри докера умел ходить в регистри и сохранять промежуточный кэш для докер регистри. Помещаю его в "алиас" команды хелма для того чтобы логически отделить запуск хелма и запуск докера. последние 2 строки - сохранить чарт в локальный кэш и подготовить для пуша в регистри и собственно запушить. Чтобы всё это работало нужно подготовить docker config.json с готовыми параметрами пользователя для доступа к докер регистри и сохранить его в переменные джобы как файл.

#helm
#gitlab
#docker
Админим с Буквой
Собираем helm-чарт в gitlab-ci и пушим в docker registry Используем экспериментальную фичу с oci-registry в которую научился хелм. Это значит что мы можем чарты теперь просто пушить рядом с контейнерами докера с таким же именованием и тегированием. deploy_helm:…
В догонку к CI о сборке чарта, CI для деплоя это чарта

в этом деплое помимо докер конфига требуется еще сделать кубконфиг, в который поместить токен админа неймспейса (1 ci = 1 app = 1 admin = 1 ns). Здесь часть сниппета, остальное что пропущено абсолютно симметрично предыдущему посту.

```
  script:
- chmod 400 $DOCKERCONFIG
- chmod 400 $KUBECONFIG
- mkdir registry
- alias helm='docker run -v ${KUBECONFIG}:/root/.kube/config -v $(pwd)/regisry:/root/.cache/helm/registry -v $(pwd):/apps -v ${DOCKERCONFIG}:/root/.docker/config.json -e DOCKER_CONFIG="/root/.docker" -e HELM_REGISTRY_CONFIG="/root/.docker/config.json" -e HELM_EXPERIMENTAL_OCI=1 alpine/helm'
- helm chart pull company.com/helm/charts/debezium:$chart_version
- helm chart export rcompany.com/helm/charts/debezium:$chart_version
- helm upgrade --install -f .......
```

#helm
#gitlab
#kubernetes
Debezium helm chart

Мы с командой Ситимобил написали helm chart для разворачивания debezium в k8s. К сожалению корпоративного репозитория у нас нет, поэтому выкладываю так (по согласованию с руководством, естественно).

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

Обратите внимание, в чарте используется подход 1 чарт = 1 коннектор, т.к. для высоконагруженных баз объединение конфигов играет злую шутку и может привести к долгому даунтайму. Приятного использования!

https://github.com/bykvaadm/debezium-helm-chart

З.ы. Дашборд для метрик выложим попозже

#debezium
#helm
#kafka
#mysql
#kubernetes
Обновление debezium helm chart

- убрали топик history
- переписали больше половины чарта
- добавили возможность использовать кафку ssl
- переписали ливнес пробу, теперь поведение перезапуска гораздо правильнее, не зависает "молча"
- добавили совместимость для postgresql
- примеры для mysql и pgsql

https://github.com/bykvaadm/debezium-helm-chart

#helm #debezium