Archiwum kategorii: dev

Optymalizacja Go dla AIX: GOPPC64 i Cross-Compile

Go, , ,

Jak zapewne wiecie, Go został zaprojektowany tak, żeby budować binaria specyficzne dla konkretnej architektury i systemu operacyjnego. Te specyficzne dla architektury i OS binaria nazywamy targetem. Możliwość cross-compile (kompilacji krzyżowej) to jedna z najfajniejszych funkcji Go – można na przykład użyć GOARCH=ppc64 GOOS=aix go build, żeby na Linuxie czy Windowsie zbudować aplikację dla systemu AIX działającego na procesorach Power. Oczywiście też nic nie stoi na przeszkodzie, żeby skompilować program bezpośrednio na AIX.

Jest jednak jeden dodatkowy trik, który bierze pod uwagę wersję architektury i optymalizuje wybór kodu ASM (assembler), używanego podczas budowania. 😉

PowerPC na AIX i zmienna GOPPC64

Żeby używać architektury Power ppc64 dla AIX z konkretnym targetem procesora, możesz skorzystać ze zmiennej GOPPC64. Oto dostępne opcje:

  • power10 – działa tylko z Power 10
  • power9 – działa z Power 9 i Power 10
  • power8 (domyślna) – działa z wersjami 8, 9 i 10

Przykładowo:

GOARCH=ppc64 GOOS=aix GOPPC64=power9 go build

Dlaczego to ma sens w środowisku AIX?
Systemy AIX często działają na konkretnych, znanych konfiguracjach serwerowych IBM. Jeśli wiesz, że Twoja aplikacja będzie działać tylko na nowszych procesorach Power (np. power9 lub power10), możesz wykorzystać dodatkowe instrukcje procesora niedostępne w starszych wersjach. Go automatycznie wybierze zoptymalizowany kod assemblerowy dla danej wersji.

Specyfika środowiska AIX

AIX to system, który często działa latami na tych samych maszynach, więc optymalizacja pod konkretny procesor może mieć długoterminowy sens. W przeciwieństwie do środowisk chmurowych, gdzie nie wiesz na czym będzie działać Twoja aplikacja, w AIX zazwyczaj masz pełną kontrolę i wiedzę o sprzęcie.

Co oczywiste, jeśli masz farmy serwerów z różnymi generacjami Power, lepiej zostać przy domyślnym ustawieniu. 🏭

Czy to rzeczywiście coś zmienia?

W typowych aplikacjach biznesowych różnica może być niewielka, ale przy:

  • Intensywnych obliczeniach matematycznych (typowe dla środowisk AIX)
  • Przetwarzaniu dużych zbiorów danych
  • Aplikacjach real-time

różnica może być zauważalna. Jak zawsze z optymalizacjami – najpierw zmierz, potem optymalizuj. 🔧

Bibliografia

Pro tip dla adminów AIX: Możesz sprawdzić wersję swojego procesora Power używając komendy prtconf | grep -i processor. Dzięki temu będziesz wiedzieć, jaką wartość GOPPC64 możesz bezpiecznie użyć.

Go / Golang – instalacja na Centos 7

Go, , ,

Red Hat Enterprise Edition, a co za tym idzie również Centos są znane z dość konserwatywnego podejścia do wersji dostępnych pakietów.
Kiedy piszę tę notatkę, w oficjalnym repozytorium CentOS dostępny Go dostępne jest w wersji 1.8.3, natomiast najnowszy stabilny release Go to wersja 1.10.
Oczywiście instalacja ze źródeł, czy też z tar.gz z binarkami to żaden problem, ale nie po to wymyślono pakiety, żeby wszystko robić na około. Są na szczęście 'dobrzy ludzie’, którzy pomyśleli o zrobieniu repozytorium z aktualnymi paczkami, można je znaleźć pod adresem: https://go-repo.io/

Ściągawka do instalacji repo:

(root)

rpm --import https://mirror.go-repo.io/centos/RPM-GPG-KEY-GO-REPO
curl -s https://mirror.go-repo.io/centos/go-repo.repo | tee /etc/yum.repos.d/go-repo.repo
yum install golang

Ściągawka do konfiguracji środowiska:
(user do kodowania)

mkdir -p ~/go/{bin,pkg,src}
echo 'export GOPATH="$HOME/go"' >> ~/.bashrc
echo 'export PATH="$PATH:${GOPATH//://bin:}/bin"' >> ~/.bashrc

Centos 7 + apache httpd >=2.4 + mod_wsgi + Python 3 + falcon

apache httpd, python,

Odpalałem ostatnio prostą aplikacyjkę napisaną w pythonie 3 z wykorzystaniem frameworka falcon. Troszkę było kombinowania.
Nie poruszam tutaj kompletnie kwestii uprawnień, selinuxa itd. Zakładam też działające apache httpd i skonfigurowanego vhosta.

  1. Dodaj repozytorium IUS do Centosa 7

    yum install https://centos7.iuscommunity.org/ius-release.rpm
  2. Zainstaluj Python 3.6, mod_wsgi i pip.

    yum install python36u-mod_wsgi python36u-pip
  3. Stwórz środowisko wirtualne 'app1′ potrzebne do uruchomienia aplikacji. Ścieżka przykładowa.

    sudo mkdir -p /srv/pythonenvs
cd /srv/pythonenvs
python3.6 -m venv app1
  4. Aktywuj venv dla swojej sesji

    source app1/bin/activate
  5. Zainstaluj falcona i wszystkie inne zależności

    (app1)$ pip install falcon
  6. Zakładam, że aplikację masz w katalogu /srv/app1/www, a 'entry point’ to main.py. Bardzo ważne! Aplikacja musi się przedstawiać serwerowi wsgi jako 'application’. To znaczy, że w kodzie falcon musi być odpalony w następujący sposób:

    api = application = falcon.API()
  7. Dodaj do konfiguracji vhosta:

    WSGIDaemonProcess app1 python-path=/srv/app1/www/ python-home=/srv/pythonenvs/app1
WSGIProcessGroup app1
WSGIScriptAlias / /srv/app1/www/main.py
<Directory /srv/app1/www/>
Require all granted
</Directory>
  8. Teraz tylko restart httpd:

    systemctl restart httpd

bash extglob odkrycie tygodnia :)

bash, Linux, ,

extglob czyli odpalenie „regexów” wewnątrz basha. Przykładowo proste kasowanie z excludem

[szydell@example test]$ ls
aaa1.txt aaa2.txt aaa3.txt aaa4.txt aaa5.txt aaa6.txt aaa7.txt aaa8.txt aaa9.txt bbb1.txt bbb2.txt bbb3.txt bbb4.txt bbb5.txt bbb6.txt bbb7.txt bbb8.txt bbb9.txt test1.txt test2.txt test3.txt test4.txt test5.txt

Chcemy wywalić *.txt z pominięciem aaa5.txt

[szydell@example test]$ shopt -s extglob
[szydell@example test]$ rm !(aaa5).txt
[szydell@example test]$ ls
aaa5.txt

[bash]Rekursywna zmiana rozszerzeń plików.

bash, , ,

Załóżmy, że mamy dużo plików o jakimś tam rozszerzeniu rozsianych w dużej ilości katalogów.
I chcemy tym wszystkim plikom zmienić rozszerzenie na jakieś inne.
np
test/bb/plik2.jpeg
test/cc/plik4.jpeg
test/cc/plik3.jpeg
test/cc/plik5.jpeg
test/aa/plik.jpeg
test/aa/dd/plik7.jpeg

chcemy te pliki. jpeg zmienić na .jpg

Rozwiązanie:
find test -name *.jpeg | awk -F '.' '{OFS=FS;var=$0;$(NF)="";print var" "$0"jpg"}' | xargs -n 2 mv

BASH: Proste, ustandaryzowane logowanie z poziomu skryptów (przy użyciu sysloga)

bash, Linux, ,

Do tego niebywale trudnego zadania, służy aplikacja logger.

usage: logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [ message ... ]

Jak widać składnia jest bardzo trudna, także przykłady

[szydell@centos ~]$ logger "Się popsuło"
[root@centos ~]# cat /var/log/messages
...
Apr 25 09:01:42 centos szydell: Się popsuło

-f /katalog/nazwapliku.log – logowanie do konkretnego pliku (zadbaj o uprawnienia)
-t SIAKISTAG – zamiast logowania jaki user uruchomił, zaloguje taga

rm z pipe’m, czyli jak posprzątać po przypadkowym wypakowaniu archiwum nie tam gdzie się chciało

bash, , , ,

Czasem w ramach roztargnienia zdarza się nam narozrabiać. Ja dzisiaj rozpakowałem sobie archiwum w miejsce, w którym mam sporo innych plików… Zrobił się konkretny bajzel, także trzeba było posprzątać.

Pierwsze co mi przyszło do głowy, to wyświetlić zawartość archiwum, użyć | rm -rf i tyle, ale okazuje się, że nie da się tak przekazać listy plików do rm i koniec. Jak zawsze z pomocą przyszedł Pan Gugiel, a właściwe rozwiązanie problemu to:

tar -tf nazwaarchiwum.tar | xargs rm -f

Proste.

bash/sed parser .ini

bash, ,

Potrzebowałem dzisiaj prosty parser, dla pliku konfiguracyjnego w moim skrypcie pisanym w bashu. Padło na .ini i genialne wygooglowane rozwiązanie

 

#!/bin/bash
CONFIG_FILE="config.ini"
SECTION="section_1"

eval `sed -e 's/[[:space:]]*\=[[:space:]]*/=/g' \
          -e 's/;.*$//' \ -e 's/[[:space:]]*$//' \
          -e 's/^[[:space:]]*//' \
          -e "s/^\(.*\)=\([^\"']*\)$/\1=\"\2\"/" \
          < $CONFIG_FILE \
          | sed -n -e "/^\[$SECTION\]/,/^\s*\[/{/^[^;].*\=.*/p;}"`

Co ważne autor pomysłu udostępnia go zgodnie z zasadami licencji WTFPL. 😉

Oryginał dostępny tu: http://www.tuxz.net/blog/archives/2011/10/19/parse__ini_files_with_bash_and_sed/