Archiv autora: Tomáš Jacík

Jak rozdělit GIT repozitář na více menších a zachovat/promazat historii

1 komentář

Semtam se stane, že se aplikace rozroste, moduly přibývají a jejich doménový model se začně čím dál více lišit. Nastal čas aplikaci rozdělit. Prvním krokem, ještě před úpravami kódu by mělo být rozdělení GIT repozitáře. Můžeme na to jít více způsoby:

1. Zkopírovat repozitář a vymazat z něj nepotřebné soubory

Je to rychlé a vcelku bezpečné. V repozitáři nám ale zůstane kompletní historie souborů ostatních aplikací a klonování každého repozitáře bude kvůli tomu trvat zbytečně dlouho.

2. Založit nový, čistý repozitář a commitnout do něj jen potřebné soubory

Je to opět rychlé a vcelku bezpečné. V repozitáři nám ale nezůstane ani historie souboru oddělované aplikace. Budeme sice mít zálohu v podobě originálního repozitáře před rozdělením, nebude se s tím ale moc pohodlně pracovat.

3. Použít git filter-branch a upravit historii zkopírovaného repozitáře

Moje oblíbená varianta. Je sice náročnější na čas a snadno se při ní udělá nějaká chyba. Odměnou je ale čistý repozitář, který obsahuje jen soubory oddělované části aplikace včetně jejich historie. Nyní si ukážeme jak na to.

Naklonujeme si originální repozitář

$ git clone git@bitbucket.org:user/repo.git new-app

Přepneme se do složky repozitáře a projistotu odstraníme jeho remote.

$ git remote remove origin

Získáme seznam všech souborů v historii včetně smazaných

Tento krok není nutný, pokud nejste puntičkáři jako já 🙂 Můžeme snadno odstranit jen soubory, které aktuálně v repozitáře nechceme. Nebo si můžeme dát trochu více práce a odstranit i soubory, které jsme už dávno smazali nebo přejmenovali. K tomu ale potřebujeme zjistit, které to byly. Pro začátek si tedy vypíšeme všechny soubory, které kdy byly do repozitáře přidány. Výstup nasměrujeme do nějakého souboru, aby se nám s ním lépe pracovalo.

$ git log --pretty=format: --name-only --diff-filter=A | sort -u > all-files.txt

Nyní přišel čas otevřít si výstupní soubor v editoru a nechat v něm jen souboru, které chceme smazat. Musíme dát pozor, abychom si nesmazali soubory, které už sice v repozitáři nejsou, ale jejich přejmenované verze chceme. V případě odstraňování celých složek můžeme ponechat jen složku místo kompletního výpisu jejich souborů.

Jakmile budeme hotovi, použijeme připravený soubor v příkazu git filter-branch k promazání historie.

$ git filter-branch --force --index-filter \
    "git rm -r --cached --ignore-unmatch `cat all-files.txt | tr '\n' ' '`" \
    --prune-empty -- --all

Nyní je načase aplikaci otestovat (v nejlepším případě spustit testy), zda jsme neodmazali něco důležitého. Nejspíše bude nutné kvůli odmazaným souborům trochu kódu upravit. Poté si můžeme přidat nový remote a udělat první push.

$ git remote add origin git@bitbucket.org:user/new-app.git
$ git push -u origin --all
$ git push origin --tags # pokud máte nějaké tagy

V této fázi jsou ještě stále staré revize zálohovány pod refs/original. Pokud je chcete z repozitáře úplně odstranit, musíme to udělat ručně.

$ git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin
$ git reflog expire --expire=now --all
$ git gc --prune=now

Eventuelně můžeme místo toho udělat čerstvý clone našeho již vyfiltrovaného remotu.

Jak dostat ze SmartOS data o prostředcích VM

2 komentáře

Na SmartOS nám spoustu věcí o VM prozradí příkaz vmadm. Např. základní limity zjistíme takto:

vmadm list -p -o uuid,alias,type,cpu_cap,cpu_shares,ram,vcpus -s -ram

Je ale docela otrava to pokaždé zadávat. Můžeme si na to samozřejmě udělat bash alias, což jsem také měl. Další užitečný alias mám např. na výpis VM:

alias vmlist='vmadm list -o uuid,type,ram,state,alias,nics.0.ip -s nics.0.ip'

Na výpis prostředků už mi ale pouhý alias nestačil. Sepsal jsem tedy jednoduchý skript. Ten krom toho, co vrací vmadm, zobrazí i kolik VM žere místa na disku v přehledné formě. Navíc je to pěkná ukázka, jak si můžete podobné užitečné skripty sepsat sami.

Rozhodl jsem se nejen skript vmusage, ale celý repozitář s pár dalšími užitečnými věcmi zveřejnit. Stahovat nebo forkovat repozitář smartos-scripts můžete na Githubu.

Jak bezpečně distribuovat hesla v gitu

Napsat komentář

Pokud už jste někdy rozcházeli deployment aplikace pomocí gitu, asi jste narazili na problém, jak na produkční server bezpečně dostat hesla. Mít je v plaintextu v GITu moc bezpečné není 🙂 Přesto ale je způsob, jak je v gitu mít bezpečně – zašifrovat je. Jak to udělat a jak je při deploymentu do produkce rozšifrovat?

Pokud nemáte, nainstalujte si na produkčním server GPG. Na Unbuntu/Debian se to dělá takto:

$ apt-get install gnupg

Pro generování klíčů budeme potřebovat hodně entropy, doporučuji tedy nainstalovat i Haveged, viz. můj minulý článek.

Nyní se potřebujeme přepnout pod uživatele, pod kterým probíhá deployment. V mém případě je to uživatel web. Pod tímto uživatelem vygenerujeme základní keypair. Důležité: nezadávejte při generování klíčů žádné heslo, jen volbu potvrďte entrem.

$ gpg --gen-key
gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory `/home/web/.gnupg' created
gpg: new configuration file `/home/web/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/web/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/web/.gnupg/secring.gpg' created
gpg: keyring `/home/web/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) "

Real name: Deployment User
Email address: web@mydomain.tld
Comment: Deployment User
You selected this USER-ID:
    "Deployment User (Deployment User) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

You don't want a passphrase - this is probably a *bad* idea!
I will do it anyway.  You can change your passphrase at any time,
using this program with the option "--edit-key".

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
...+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.+++++
.......+++++
gpg: /home/web/.gnupg/trustdb.gpg: trustdb created
gpg: key 6C791601 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   4096R/6C791601 2016-01-15
      Key fingerprint = B690 9E58 FA2C EAE6 008F  1A2E 88CD 1D28 6C79 1601
uid                  Deployment User (Deployment User) 
sub   4096R/BF95086E 2016-01-15

Teď když máme vygenerovaný keypair, vyexportujeme veřejný klíč, nejlépe do souboru:

$ gpg --armor --export web@mydomain.tld > public.key

To by bylo pro produkční server zatím vše. Nyní si na našem vývojovém stroji vygenerujeme keypair stejně jako na produkčním serveru. Tentokrát ale doporučuji zadat heslo, na které se se vás GPG při šifrování a dalších operacích bude ptát. Poté importujeme veřejný klíč produkčního serveru.

$ gpg --import public.key
gpg: key 6C791601: public key "Deployment User (Deployment User) " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Importovaný klíč podepíšeme, tím řekneme GPG, že důvěřujeme jeho původu:

$ gpg --sign-key web@mydomain.tld

pub  4096R/6C791601  created: 2016-01-15  expires: never       usage: SC  
                     trust: unknown       validity: unknown
sub  4096R/BF95086E  created: 2016-01-15  expires: never       usage: E   
[ unknown] (1). Deployment User (Deployment User) 


pub  4096R/6C791601  created: 2016-01-15  expires: never       usage: SC  
                     trust: unknown       validity: unknown
 Primary key fingerprint: B690 9E58 FA2C EAE6 008F  1A2E 88CD 1D28 6C79 1601

     Deployment User (Deployment User) 

Are you sure that you want to sign this key with your
key "Developer User (Developer User) " (1BDC2E07)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "Developer User (Developer User) "
4096-bit RSA key, ID 1BDC2E07, created 2016-01-15

gpg: problem with the agent - disabling agent use
Enter passphrase:

Teď přijde ta hlavní část. Zašifrujeme veřejným klíčem produkčního serveru konfigurační soubor s hesly:

$ gpg --output prod.conf.gpg --encrypt --recipient web@mydomain.tld prod.conf

Zašifrovaný soubor .gpg pak můžeme bez problémů commitnout do gitu. Bez privátního klíče produkčního serveru jeho obsah nikdo nepřečte. Na produkčním serveru pak v deployment procesu nastavíme rozšifrování tohoto souboru pomocí privátního klíče, který už na serveru máme.

$ gpg --output local.conf --decrypt prod.conf.gpg
gpg: encrypted with 4096-bit RSA key, ID BF95086E, created 2016-01-15
      "Deployment User (Deployment User) "

Jak zrychlit generování certifikátů v linuxu

1 komentář

Při generování certifikátů systém potřebuje tzv. entropy. Kolik jej systém aktuálně má můžete zjistit tímto příkazem:

$ cat /proc/sys/kernel/random/entropy_avail

Protože se entropy získává především z uživatelského vstupu, je s ním na serveru trochu problém. Tenhle problém řeší Haveged. Jak to celé pracuje je hezky vysvětleno v článku How to Setup Additional Entropy for Cloud Servers Using Haveged.

Člověk si chce jednou za čas udělat něčím radost, např. novou grafickou kartou. Tak jsem si takhle vyhlédl a objednal MSI GTX 960 GAMING 2G. Karta se mi moc zamlouvala a dnes dorazila domů. To bych to ale měl moc jednoduché, abych ji jen nainstaloval a začala fungovat 🙁 Karta zdá se není kompatibilní s mojí deskou, která je hádejte co – taky MSI 🙂 Konkrétně Z77A-GD65. Ať laboruji jak chci (upgrade BIOSu, reset CMOS, jiný PCI-E slot), karta ne a ne fungovat.

GTX 960 Gaming 2G

I rozhodl jsem se, že napíšu přímo na podporu MSI. Jsou to přeci obojí jejich produkty, tak snad poradí, no ne? Abych mohl položit dotaz, musím ale projít registrací. Registrace už tak sama o sobě zdlouhavá, kde po vás chtěji vědět kde co, ale dá se to přežít. Nakonec nabídne registraci produktu, tak si říkam, když už jsem došel sem, proč ne. Zadal jsem tedy sériové číslo, ale to jim nestačilo. Chtěli ještě sériové číslo 2. Po důkladném hledání a opisování každého čísla, které jsem na krabici nebo kartě viděl, jsem se nakonec dobral k tomu, že jde o ten nejmenší, bez silné lupy naprosto nečitelný štítek.

GTX-960-Gaming-2G-SN

Navíc je v tom číslu tečka, ale tu tam zadávat nesmíte, jinak to neprojde 🙂 A to jsem ještě zapomněl dodatat, že když to číslo zadáte špatně, tak ho nestačí umazat. Při pokusu o znovu zadávání se stále cosi načítá, až se to načítat přestane a skončíte na černé obrazovce (jako já s tou kartou). Musíte tedy pokaždé dát zpět (díky bohu se první SN nesmaže) a poté znovu potvrdit, abyste mohli zadávat znovu.

Ale to nejlepší, ten zlatý hřeb nakonec. Už se radujete, jásáte, že máte vše vyplněno, kliknete odeslat a – no chyba 404 🙂 MSI, už nikdy víc.

PS: Ten dotaz jsem nakonec odeslal (musel jsem znovu vyplňovat sériové číslo). Jsem zvědav, zda mi odpoví.

Jak vytvořit Ubuntu image pro SmartOS

Napsat komentář

Po nějaké době vás přestane bavit instalovat všechny nové VPS z ISO image. Nastal čas vytvořit si image pro imgadm. Jak na to?

Vytvoříme si prázdný VPS:

$ vmadm create <<EOF
{
	"alias": "ubuntu-14-04-3",
	"brand": "kvm",
	"autoboot": false,
	"vnc_port": 12300,
	"vcpus": 1,
	"ram": 1024,
	"cpu_cap": 100,
	"cpu_shares": 100,
	"zfs_io_priority": 100,
	"max_lwps": 2000,
	"quota": 10,
	"disks": [
		{
			"boot": true,
			"model": "virtio",
			"size": 10240

		}

	],
	"resolvers": ["8.8.8.8", "8.8.4.4"],
	"nics": [
		{
			"nic_tag": "admin",
			"model": "virtio",
			"ip": "x.x.x.x",
			"netmask": "255.255.255.0",
			"gateway": "y.y.y.y",
			"primary": true
		}
	]

}
EOF
Successfully created VM e736e906-5cca-49e8-a0e0-7a3367ee6841

Stáhneme instalační ISO a nabootujeme z něj VPS:

$ cd /zones/e736e906-5cca-49e8-a0e0-7a3367ee6841/root
$ wget -q http://releases.ubuntu.com/trusty/ubuntu-14.04.2-server-amd64.iso
$ vmadm boot e736e906-5cca-49e8-a0e0-7a3367ee6841 order=cd,once=d cdrom=/ubuntu-14.04.3-server-amd64.iso,ide
Successfully started VM e736e906-5cca-49e8-a0e0-7a3367ee6841

Získáme info o VNC a připojíme se na něj:

$ vmadm info e736e906-5cca-49e8-a0e0-7a3367ee6841 vnc

Nyní nainstalujeme Ubuntu (nebo jiný OS) jak jsme zvyklí. U ubuntu ještě doporučuji pomocí F4 zvolit volbu „Install a minimal virtual machine“.

Po instalaci uděláme aktualizaci systému a reboot:

$ sudo su
$ aptitude update
$ aptitude dist-upgrade
$ reboot

Po rebootu odstraníme staré kernely:

$ sudo su
$ dpkg -l|grep linux
ii  libselinux1:amd64               2.2.2-1ubuntu0.1                 amd64        SELinux runtime shared libraries
ii  linux-headers-3.19.0-25         3.19.0-25.26~14.04.1             all          Header files related to Linux kernel version 3.19.0
ii  linux-headers-3.19.0-25-generic 3.19.0-25.26~14.04.1             amd64        Linux kernel headers for version 3.19.0 on 64 bit x86 SMP
ii  linux-headers-3.19.0-26         3.19.0-26.28~14.04.1             all          Header files related to Linux kernel version 3.19.0
ii  linux-headers-3.19.0-26-generic 3.19.0-26.28~14.04.1             amd64        Linux kernel headers for version 3.19.0 on 64 bit x86 SMP
ii  linux-headers-generic-lts-vivid 3.19.0.26.13                     amd64        Generic Linux kernel headers
ii  linux-headers-virtual-lts-vivid 3.19.0.26.13                     amd64        Transitional package.
ii  linux-image-3.19.0-25-generic   3.19.0-25.26~14.04.1             amd64        Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii  linux-image-3.19.0-26-generic   3.19.0-26.28~14.04.1             amd64        Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii  linux-image-virtual-lts-vivid   3.19.0.26.13                     amd64        This package will always depend on the latest minimal generic kernel image.
ii  linux-virtual-lts-vivid         3.19.0.26.13                     amd64        Minimal Generic Linux kernel and headers
ii  util-linux                      2.20.1-5.1ubuntu20.6             amd64        Miscellaneous system utilities
$ aptitude purge linux-headers-3.19.0-25 linux-headers-3.19.0-25-generic linux-image-3.19.0-25-generic

Volitelně také můžeme vyhodit hlavičkové soubory, které ve většině případů nejsou potřeba, ale aktualizují se zbytečně s každým kernelem:

$ aptitude purge linux-headers-3.19.0-26 linux-headers-3.19.0-26-generic linux-headers-generic-lts-vivid linux-headers-virtual-lts-vivid linux-image-virtual-lts-vivid linux-virtual-lts-vivid

Můžeme doinstalovat nějaké balíky. Rozhodně ale nesmíme vynechat balík acpid:

$ aptitude install acpid arping htop mc

Některé přebytečné balíky se hodí vyhodit:

$ aptitude purge usbutils pppoeconf pppconfig ppp popularity-contest pciutils ntfs-3g laptop-detect apparmor libapparmor-perl

Dále nainstalujeme sdc-vmtools:

$ cd /usr/src
$ wget https://github.com/joyent/sdc-vmtools/archive/master.zip
$ aptitude install unzip
$ unzip master.zip
$ cd sdc-vmtools-master/src/linux
$ ./install-tools.sh -y
$ cd /usr/src
$ rm -r sdc-vmtools-master/ master.zip

Přihlásíme se přes VNC a ostraníme uživatele, kterého jsme vytvořili při instalaci systému:

$ sudo su
$ passwd
# Relogin jako root
$ userdel user
$ rm -r /home/user

Připravíme VPS na vypnutí:

$ /lib/smartdc/prepare-image

Rootovi můžeme nyní odebrat heslo:

$ passwd -d root

Shodíme VPS a vratíme se do SmartOS:

poweroff

Vytvoříme z VPS image:

$ zfs create zones/images
$ zfs snapshot `vmadm get e736e906-5cca-49e8-a0e0-7a3367ee6841|json disks.0.zfs_filesystem`@final
$ zfs send `vmadm get e736e906-5cca-49e8-a0e0-7a3367ee6841|json disks.0.zfs_filesystem`@final | bzip2 --best > /zones/images/ubuntu-14.04.3-server-amd64.zvol.bz2

A VPS smažeme:

$ vmadm destroy e736e906-5cca-49e8-a0e0-7a3367ee6841
Successfully deleted VM e736e906-5cca-49e8-a0e0-7a3367ee6841

Pro image potřebujeme vytvořit dsmanifest:

cd /zones/images
cat > ubuntu-14.04.3-server-amd64.dsmanifest <<EOF
{
	"uuid": "`uuid`",
	"creator_name": "organizace",
	"creator_uuid": "ef16d6fc-51a7-11e5-8793-67c0a6dc6ee3",
	"vendor_uuid": "ef16d6fc-51a7-11e5-8793-67c0a6dc6ee3",
	"name": "ubuntu64",
	"version": "14.04.3",
	"urn": "sdc:organizace:ubuntu64:14.04.3",
	"type": "zvol",
	"os": "linux",
	"description": "Ubuntu 14.04.3 LTS Server x86-64 VM image",
	"created_at": "2015-09-02T21:14:00Z",
	"updated_at": "2015-09-02T21:14:00Z",
	"files": [
		{
			"path": "ubuntu-14.04.3-server-amd64.zvol.bz2",
			"sha1": "`shasum ubuntu-14.04.3-server-amd64.zvol.bz2|awk '{print $1}'`",
			"size": `ls -l ubuntu-14.04.3-server-amd64.zvol.bz2|awk '{print $5}'`
		}
	],
	"image_size": "10240",
	"requirements": {
		"networks": [
			{
				"name": "net0",
				"description": "public"
			}
		],
		"ssh_key": true
	},
	"platform_type": "smartos",
	"cloud_name": "sdc",
	"cpu_type": "host",
	"disk_driver": "virtio",
	"nic_driver": "virtio",
	"generate_passwords": "true",
	"users": [
		{"name": "root"}
	]
}
EOF

UUID pro creator_uuid a vendor_uuid si můžete vygenerovat příkazem uuid.

Máme image a dsmanifest, teď image můžeme nainstalovat:

imgadm install -m ubuntu-14.04.3-server-amd64.dsmanifest -f ubuntu-14.04.3-server-amd64.zvol.bz2

A teď z image konečně vytvoříme VPS:



Nemá smysl dávat disku větší size, než je size image. Disk se stejně vytvoří podle image. Prozatím to řeším pomocí GParted. Jakmile budu vědět, jak to zautomatizovat, napíšu o tom další článek. Nebo můžete někdo poradit v diskuzi pod článkem 🙂


Dodatek: dá se to řešit takto:


# V global zóně
$ zfs set volsize=54G zones/7dc89552-48fd-4fb7-9dfa-470ee47502b3-disk0
# Ve VPS
$ fdisk /dev/vda

Command (m for help): d
Selected partition 1

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-113246207, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-113246207, default 113246207):
Using default value 113246207

# Reboot
$ resize2fs /dev/vda1
# Reboot


					

		
		
	

							
	

				

			
						

				Jak připravit SmartOS na Ansible
			

										

					Napsat komentář				

					


				

			
Se SmartOS je po instalaci trochu problém. Aby na něm Ansible fungoval, je potřeba pár věcí udělat ručně.


Nainstalovat pkgsrc bootstrap do globální zóny:


$ cd /
$ curl -k http://pkgsrc.joyent.com/packages/SmartOS/bootstrap/bootstrap-2014Q4-x86_64.tar.gz | gzcat | tar -xf -
$ pkg_admin rebuild
$ pkgin -y up



Můžeme rovnou provést upgrade balíků:


$ pkgin full-upgrade



Doinstalujeme python:


$ pkgin in python27



Volitelně povolíme ssh klíč:


mkdir ~/.ssh
echo "" > ~/.ssh/authorized_keys
chmod 700 .ssh
chmod 600 .ssh/*



Pokud nechcete přidávat klíč, stačí spustit ansible-playbook s prametrem -k, aby se zeptal na heslo.

					

		
		
	

							
	

				

			
						

				Efektivní předávání datových struktur mezi PHP aplikacemi
			

										

					Napsat komentář				

					


				

			
Pokud budete muset řešit předávání dat mezi (PHP) aplikacemi, např. přes RabbitMQ nebo Kafku, jistě vás napadne je buďto serializovat (to ovšem funguje jen v rámci PHP) nebo použít JSON (XML je dle mého názoru přežitek).


Neexistuje ale lepší, efektivnější způsob? Ale ano, jmenuje se BSON! A PHP jej podporuje pomocí extension Mongo funkcemi bson_encode() a bson_decode(). Encode/decode je navíc rychlejší nejen než JSON, ale také než serialize(). Je libo nějaké testy?