обращение по DNS в kubernetes между namespace

Исходные данные:
service name = jenkins
namespace = jenkins

Тогда, например, для пуша в jenkins можно сформировать такой web-hook:

http://<user>:<token>@jenkins.jenkins.svc.cluster.local:8080/job/my-super-job/build

#kubernetes #jenkins #git

Список тегов, используемых в канале:

—-------------------------------
Лекции и материалы
—-------------------------------
#Занятие
#Лекции
Лекция
#junior

—---------
Linux
—---------
#ssh
#bash
#bash_tips_and_tricks
#awk
#tmux
#console
#utils
#troubleshooting
#nmap
#apt
#bind
#sound
#power_management

—----------
DevOps
—----------
#jenkins
#ansible
#git
#kubernetes
#deploy
#ceph
#docker
#puppet

—------------------
Virtualization
—------------------
#vmware
vagrant

—------------------
Networking
—---------------—
#networking
#proxy
#socks

—---------
InfoSec
—---------
#vulns
#security
#ctf

—-------------
Windows
—-------------
#RDTS
#windows_server2012
#RDP

—------------
Datacenters
—---------—
#ovh
#hetzner

—-------
Other
—-------
#android
#jira

—------------------------------------------------
Ссылки и сторонние материалы
—------------------------------------------------
#read
#thirdparty

Updated: 29.05.18

git undoing operations

Хорошая статья, которая показывает как правильно и красиво поступить в ситуации, когда нужно что-то откатить\удалить в ветке коммитов.

https://sethrobertson.github.io/GitFixUm/fixup.html

#git #troubleshooting

Git commit messages

Как правильно комиттить в гит. Хорошая статья с хабра:

https://habr.com/post/416887/

#thirdparty #read #git

Книга про гит на русском. Это для тех людей, кто вдруг ее еще не видел. Или вдруг еще даже не пользовался никогда гитом. Самое время начать!

#git

GIT отделить ветку в отдельный репозиторий

вариант 1:

git push url://to/new/repository.git branch-to-move:new-branch-name

вариант 2:

git clone -b newbranch CurrentRepo NewRepo

#git

мини-заметка без заголовка
^^^ это не заголовок
(типа пошутил, да)

шобы хранить файлы libreoffice в гите, так чтобы гит не считал их как бинарники (и соответственно на изменение каждой запятой не создавал его клон), можно сменить формат на Flat XML, например fodt, fods.

#git

заставляем 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

Поиск по git

Поиск коммитов, связанных с файлом (даже если удален)

git log --all -- somefile

Поиск коммитов, фильтруя по тексту коммита

git log -g --grep=STRING

#git

git revert multiply commits

Дано:

A <-- B  <-- C <-- D <-- master <-- HEAD

Хотим:

A <-- B  <-- C <-- D <-- [(CD)^-1] <-- master <-- HEAD

Решение:

$ git revert --no-commit D
$ git revert --no-commit C
$ git commit -m "the commit message"

еще это можно решить так:

$ git checkout -f B -- .
$ git commit -a

#git

Untrack files already added to git repository based on .gitignore

1) git rm -r --cached .
2) git add .
3) git commit -m ".gitignore fix"

#git

git stage only one line

Поковырял вчера доки, в итоге оказалось что стейжить одну строчку можно, но есть нюансы. о чем идет речь? например у вас есть файл, в котором условно вы работаете и в какой-то момент, не важно зачем хотите сделать коммит, но поместить туда не все наработки а только часть их. Раньше я прекрасно с этим справлялся, используя git add -p и работал с hunk'ами, которые для меня разбивал гит. хочешь добавить в коммит кусок? жми y, не хочешь - жми n. Все было хорошо, пока изменения которые я хочу добавить и которые не хочу не попали в один hunk. В таком случае можно попросить git выполнить разбиение этого hunk на несколько, с помощью команды s (split). И тут появляется нюанс - изменяемые строки не должны быть соседними. Во всем остальном разбиение произойдет без проблем.

UPD говорят что еще довольно удобно такие операции делать в tig. Сам не проверял, за вопросами по работе tig приходите в чят

#git

git reset modifications only in one file

Полный откат изменений - git reset --hard, но когда нужно только один файл откатить - подойдет такая команда:

git checkout -- path_to_file/file_name

UPD доп инфо для прочтения: https://stackoverflow.com/questions/6561142/difference-between-git-checkout-filename-and-git-checkout-filename/6561160#6561160

#git

Еще одна полезная особенность cherry-pick

Если master сильно отличается от stage ветки, ввиду каких-либо обновлений продукта на бою по воле заказчиков, а разработка требует изменять файлы сначала в stage для получения одобрения заказчика. То можно использовать cherry-pick, выдергивая только те коммиты, которые уже вылили на stage и были протестированы заказчиком. Часто касается проектов на поддержке. Когда нет времени актуализировать хосты разработчиков.

Последовательность действий в таких случаях следующая:

git checkout stage
git checkout -b task_1_stage

Вносите необходимые изменения по задаче которая у вас стоит

git commit -m"#1 example changes for task 1"
git checkout stage
git merge task_1_stage

После одобрения заказчиком на стейдже

git checkout master
git checkout -b task_1_master
git cherry-pick ID*
git checkout master
git merge task_1_master

* - ID: идентификатор коммита в ветке task_1_stage

Вот и всё, нужный нам коммит перенесен в master и находится в верхней точке ветки. Таким образом можно переносить и несколько коммитов по надобности, последовательно выполняя cherry-pick от раннего к позднему коммиту.

#git

#git для новичков)