Docker

 ( makgab | 2015. augusztus 20., csütörtök - 19:19 )

Üdv!

A Docker-t nézegetem, egész jó (hoszt: FC22 x64), a cockpit webes felület is használható.
Lekaptam a Fedora docker imaget: https://getfedora.org/hu/cloud/download/docker.html
Valamint a centos7-et: docker pull centos:7

Létre is hoztam a konténereket:
docker create --name="fedora22" --hostname="fedora22" -t -i < Imagename >
docker create --name="centos7" --hostname="centos7" -t -i < Imagename >

El is indultak:
docker start fedora22
docker start centos7

Be is tudok lépni:
docker attach fedora22
docker attach centos7

Néhány dolog még nem egészen ok:
* Utólag hogy tudok fix IP-t adni a konténereknek? Konfigba kellene valahogy beírni?
* Milyen módon lehetséges szolgáltatás automatikus elindítása? A "systemctl enable sshd" ugye pl. nem használható a docker konténerben.
* A "sysctl net.ipv4.conf.all.forwarding" 1-et ad vissza. A centos-on az sshd-t futtatom, de a fedora konténerről nem tudok bessh-zni. Mi hiányozhat?

centos7 /]# ps ax
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 /bin/bash
141 ? S 0:00 /usr/sbin/sshd -D
147 ? Ss 0:00 httpd
148 ? S 0:00 httpd
149 ? S 0:00 httpd
150 ? S 0:00 httpd
151 ? S 0:00 httpd
152 ? S 0:00 httpd
155 ? R+ 0:00 ps ax

fedora22 /]# ssh 172.17.0.1
ssh: connect to host 172.17.0.1 port 22: No route to host

(A hosztról a httpd elérhető a centos7 konténeren.)
(A networking-et tanulmányozom, de valamit elrontok.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

* Milyen módon lehetséges szolgáltatás automatikus elindítása? A "systemctl enable sshd" ugye pl. nem használható a docker konténerben.

https://docs.docker.com/articles/using_supervisord/

Ne ez nem működik.

# cat /etc/supervisor/conf.d/supervisord.conf
[supervisord]
nodaemon=true

[program:sshd]
command=/usr/sbin/sshd -D

[program:httpd]
command=/usr/sbin/httpd

Semmi sem történik. Konténer stop, start, attach a folyamatok között semmi.

Nekem működik, elindul a /usr/bin/supervisord?

Az se indul, mert nem látni. Ha az elindulna, akkor a többi se lenne gond. :)
A "Dockerfile"-nak léteznie kellene valahol?

Azt Te hozod létre, ami alapján utána lefut a build.

Én nem hoztam létre semmi ilyet, ahogy a témaindítóban írtam, csak annyit csináltam.

Akkor próbáld végig azt ami a linken van, mert az a baj hogy a Docker nem fogja tudni hogy mit kell elindítani, vagy a másik megoldás hogy /bin/bash helyett a /usr/bin/supervisord -t indítod el.

A "/usr/bin/supervisord"-t hiába írom be, semmit nem csinál. Ha belépek a konténerbe:
# /usr/bin/supervisord -c /etc/supervisor/conf.d/supervisord.conf &
[3] 58
/]# 2015-08-20 20:30:49,276 CRIT Supervisor running as root (no user in config file)
2015-08-20 20:30:49,280 INFO supervisord started with pid 58
2015-08-20 20:30:50,283 INFO spawned: 'httpd' with pid 61
2015-08-20 20:30:50,285 INFO spawned: 'sshd' with pid 62
2015-08-20 20:30:50,299 INFO exited: sshd (exit status 1; not expected)
2015-08-20 20:30:50,321 INFO exited: httpd (exit status 1; not expected)
2015-08-20 20:30:51,324 INFO spawned: 'httpd' with pid 63
2015-08-20 20:30:51,327 INFO spawned: 'sshd' with pid 64
2015-08-20 20:30:51,343 INFO exited: sshd (exit status 1; not expected)
2015-08-20 20:30:51,364 INFO exited: httpd (exit status 1; not expected)
2015-08-20 20:30:53,369 INFO spawned: 'httpd' with pid 65
2015-08-20 20:30:53,372 INFO spawned: 'sshd' with pid 66
2015-08-20 20:30:53,389 INFO exited: sshd (exit status 1; not expected)
2015-08-20 20:30:53,410 INFO exited: httpd (exit status 1; not expected)
2015-08-20 20:30:56,415 INFO spawned: 'httpd' with pid 67
2015-08-20 20:30:56,417 INFO spawned: 'sshd' with pid 68
2015-08-20 20:30:56,432 INFO exited: sshd (exit status 1; not expected)
2015-08-20 20:30:56,444 INFO gave up: sshd entered FATAL state, too many start retries too quickly
2015-08-20 20:30:56,455 INFO exited: httpd (exit status 1; not expected)
2015-08-20 20:30:57,457 INFO gave up: httpd entered FATAL state, too many start retries too quickly

Ha belépek a konténerbe (docker attach centos7), akkor indulna el a supervisord. :o

"Docker nem fogja tudni hogy mit kell elindítani"

Ezt nem egészen értem, hogy hol/hogyan adható meg, hogy mit indítson a Docker.
A "Dockerfile" fájlt nem is hoztam létre, ennek hol lenne a helye?

A Dockerfile csak a elkszít egy image-t, ahhoz kell. Ha jól értem a doksit.
Kész konténert szeretnék konfigurálni.
Vagy rosszul értelmezem?

A konténerek read-only módban futnak. Ha befejeződik a 1-es számú processz kilép és minden változtatásod megy a levesbe.

Az image-ból létrehozott konténerben telepítettem csomagokat. Azok megmaradtak a következő indításkor.
Vagy milyen változások vesznek el?

Nézd meg az oktató videókat a docker oldalán.

Megnéztem a Docker videokat, nagyon jók. Egész jól megy a Dockerfile használata... :)
Tehát az image-k olvashatók (read-only), a konténerek az "írható réteg". Egy image-ből létrehozott konténerben a változások benne maradnak a konténerben leállítás után is.
Persze a konténerben a változást bele lehet tenni (commit) egy új image-be (új csomagtelepítés, konfig állományok módosítása... stb.).

Valami felett átsiklottam? Vannak olyan "konténer módosítások", amik nem mentődnek el? (A videokon nem láttam ilyen példát.)

Igen. Az összes módosítást kvázi snapshot rétegekben tárolja, ezek eldobása igen könnyű (annyira hogy amikor elmentettem image-ként a konténeremet mentés gyanánt, a kiinduló állapotot mentette el, mert kihagytam a külön megadandó paramétert hogy görgesse rá a változásokat).
Ha csak leállítod a konténert, majd start-tal indítod run helyett, akkor megmaradnak a dolgaid. De alapvetően ez arra lenne kitalálva hogy mindig az adott futásokra jön létre egy friss konténer az image-ből.

A videon is láttam, hogy a run az image-ből hoz létre egy új(!) konténert (és indítja).
Ha ez a konténer leáll, majd később újból indítod, akkor abban benne lesznek a változások. Ha run-al indítasz mégegy konténert, abban az előző run változások nem lesznek benne, mert a run mindig egy új konténert hoz létre az image-ből. Ez világos.
Éles környezetben a run-al létrehozott/indított konténert később újra lehet indítani. Gondolom a run az első létrehozásra és indításra való(?).

Ehhez kapcsolódik a kérdésem: Éles környezetben ki hogyan használja a docker-t?
Tehát adott egy app, pl. php-alapú weboldal+mysql vagy java-alapú weboldal (mysql+tomcat).
* Miért jobb a mysql-t és az apache-ot külön konténerbe tenni? Az egyik docker videon is ez látható. Ezt nem egészen értettem miért jó. Miért "rosszabb" megoldás, ha egy konténerben van az apache/php és a mysql is. (Pl. egy supervisord-vel indítom őket.) Amiatt jobb esetleg, hogy ugyanaz a mysql több konténerhez is használható, tehát "spórolni" lehet vele?

A konténert alapvetően úgy kellene felépíteni, hogy állapotmentes legyen. Azaz a konfigját környezeti változókból kapja, az adatait pedig egy csatolt data only konténerben tárolja.
Ha így építkezel, akkor egy alkalmazás frissítése annyit jelent, hogy letöltöd a friss image-et, eldobod a régi konténert, és elindítasz egy újat (run). Adat, konfig pedig ugye maradt.

Ha egybeépítetted a webszervert az adatbázissal, akkor ezt a kettőt már neked kell karbantartanod kézzel, interaktívan belépve a konténerbe.
Próbálj elszakadni a full stack virtuális gép fogalmától. Építkezz úgy, hogy ne kelljen "üzemeltetned" a konténer tartalmát. Ne is akarj interaktívan belépni.

Persze a fentiekhez nagyon ideális körülmények és sok türelem kell, így ha már tudod hogy miért hágod át ezeket a szabályokat, nyugodtan megteheted. De amíg tanulsz, próbáld betartani őket.

Már értem, köszönöm!
Valóban, egy kicsit gondolatban nem tudtam elszakadni a többi virtualizációs technológiától.

Tehát az adatok (SQL) egy konténerben vannak, amiben csak pl. a mysql v. pgsql fut (egy "sql" image-ből). Maga az alkalmazás egy másik konténerben fut (run-al indítva egy "app" image-ből).
Ha változik az app (pl. frissül), akkor csak az "app" image-t kell frissíteni és lehet egy új konténerben indítani (run) az új app-ot.

Jó ez a Docker elképzelés. :)

na es hova tenned / hogy oldanad meg a kontenerben futo alkalmazas konfigfile-jat, amibe modositasok is kerulhetnek?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"na es hova tenned / hogy oldanad meg a kontenerben futo alkalmazas konfigfile-jat, amibe modositasok is kerulhetnek?"

Egy alkalmazas konfigfajljaba a kontener eletciklusa soran tipikusan nem kerulnek modositasok, azokat az image modositasaval erjuk el, majd elindul egy uj kontener.

De a legtobb esetben olyant is szoktak csinalni, hogy a konfig valtasokat a kornyezeti valtozokban kommunikaljak le, majd ujraepul a kontener, a fix adatokat meg ugyis alacsatoljak.
--
Blog | @hron84
Üzemeltető macik

+1

Az a konfigfajl ami futasidoben valtozik, az inkabb konfig adatbazis->mehet csatolt adatkontenerbe

Vagy esetleg etcd.

CoreOS-en kívül használtad már? Kíváncsi lennék a tapasztalatokra

CentOS-on játszottam vele pár percet, de semmi több. Úgyhogy inkább én volnék kíváncsi a tapasztalatokra. Gondolom értelmesebb, mint adatkonténerben beállítást változtatni és docker kill-lel SIGHUP-ot beküldeni.

Jelenleg szerintem nincs ertelmes alternativa CoreOS-en kivul docker futtatasara. Nekunk fut production-be coreos.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Amikor utoljára néztem, pont a klasztermegoldása ipari gány volt (CoreOS fórumokon is szégyennek tartották), de ez mondjuk egy éve volt, amilyen tempóban fejlődik azóta biztos javult. Milyen a HA illetve a kompatibilitási tapasztalat? Docker vagy rocket alapon használjátok?
Tervezem hogy újra előveszem, ha van olyan amibe nagyon beletenyereltetek, örülnék ha megosztanád.

Valoban szar volt az elejen. Mostanaba eleg sokan at tertek ra. Nekem jelen allas szerint stabbilnak tunik napi mukodesbe. Ami szamunkra a hozza adot ertek az fleet meg az etcd amit ki hasznalunk teljesen. Erre epul a sajat autodeployment megoldasunk.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

az etcd melyik verziojat hasznaljatok?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Elesben jelenleg 0.4.x
Stagingen meg 2.0.x.

De elesben csak CoreOS 8xx-tol fogunk at allni valszeg.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

A full stack webszerver meg normal virtualis gepben (Amazon EC2 pl) is rettenetesen rossz megoldas, en mostanaban egyre kevesbe javaslom.

Eloszor is, ha megszalad egy PHP alkalmazas (mert meg tudnak szaladni), akkor van olyan forgatokonyv, amikor a MySQL nem tisztan lep ki, es ez nem tesz jot az adatbiztonsagnak. A masik az eroforras-versenyhelyzet, amikor egy szarul megirt PHP alkalmazas elstartol egy heavy SQL query-t, az oldalt meg parhuzamosan 100-200 ember kerdezgeti.

Teljesitmenyoptimalizalasi szempntbol az a jo, ha minel tobb, egymastol kulonallo, onallo eroforraskorlatokkal rendelkezo gepen/kontenerben futnak az eroforrasigenyes cuccok, mert ezzel no a rendszer szumma throughputja.

--
Blog | @hron84
Üzemeltető macik

Ezert is jo kontenerezni, mert bar annyi rugalmassag nincs, mint ha kulon gepen lennenek a szolgaltatasok, de azert lehet konfiguralni az eroforrasokat, cserebe nem is koltseges annyira, mint a masik.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

A Dockerfile-t minden esetben kézzel kell létrehozni? Mármint ez úgymond egy "recept" a készülő image-hez, amibe ilyen módon mondjuk egy VestaCP-t(https://vestacp.com/) felvenni elég hosszadalmas lenne.

Ebben van egy tonna alkalmazás. A docker nem erre való.

Valójában azért szúrt szemet, mert a Hubon van egy ilyen: cassa/vestacp image egész komoly letöltés számmal. Ezzel a manuális módozattal pedig elképzelhetetlennek tartom, hogy valaki összeállította volna.

A vestacp installja 3 sor. Indítasz egy csupasz ubit interaktív módban, majd kézzel lefuttatod benne ezt a 3 sort, voila. Cassa megoldása vsz ugyanilyen, merthogy a dockerfile-t már nem rakta ki ;)

Elvileg ez a Dockerfile tartozik hozzá: http://paste.ubuntu.com/12626755/
Bár nem értem, hogyan...

Szerintem igazabol meg senki nem tudja, mire valo igazan a Docker, ezert hasznaljak mindenre, amit bele tudnak szuszakolni. Vannak persze elvek, de az mindenkinek lehet.
--
Blog | @hron84
Üzemeltető macik

Mibol gondolod ,hogy senki se tudja? Azert eleg teves feltetelezes.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Jelenleg a puding próbája szakasz van. Mindenki használja valamire. Aki el tud vonatkoztatni a fullstack virtuálgép fogalmától, és az alaklmazásfejlesztése már átállt microservices alapúra, az az eddigi tapasztalatok alapján jól jön ki belőle, a többiek nem, vagy legalábbis kisebb eséllyel. De nincs igazából kiforrott iparági gyakorlat mire is jó igazán, ezért van az a közhiedelem hogy senki nem tudja mire jó.

ezért van az a közhiedelem hogy senki nem tudja mire jó.

azert hrgy84 velemenyet ne azonositsuk mar a kozhiedelemmel...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Atfogalmazom: mindenkinek van egy elkepzelese, hogy mire valo a Docker, de ezek kozott nincs feltetlenul osszefugges. Bazso-nak van egy elkepzelese, amibe nem fer bele az 1-nel tobb alkalmazas futtatasa egy konteneren belul, ezen osztoznak paran, a VestaCP fejlesztoinek meg van egy masik elkepzelese, miszerint boven belefer egy komplett control panel (+ fuggosegek) a Docker korlataiba, es ezen is osztoznak paran.

En azt gondolom, hogy hiba egy Docker-jellegu szolgaltatast beskatulyazni, jobb lenne, ha mindenki szabadon hasznalhatna arra, amire valo, anelkul, hogy ezert barkitol letorkolast kapna, hogy "de hat ez nem erre van". Ez az en elkepzelesem, es jelenleg nem tudom, hogy barki is osztozna rajta, de szivesen varom a csatlakozni vagyokat. Az elkepzelesem CC-BY licences, szabadon terjesztheto.
--
Blog | @hron84
Üzemeltető macik

+1. Orális örömöket szemlélni (más szív vele), avagy önszivatásnak tökéletes :-P

"Utólag hogy tudok fix IP-t adni a konténereknek? Konfigba kellene valahogy beírni?" Nem szokas, es a docker sem tamogatja a fix ip-t. Van egy rakas lehetoseg arra, hogy masok szamara elerheto legyen a kontener attol fuggoen mit szeretnel csinalni, es kik azok a masok. Lehet natolni a hostrol vagy net+host-al a hostra kitenni portot, de lehet net=containerrel kontenerket osszekotni, lehet osszelinkelni kontenereket, lehet privat halozatot letrehozni a kontenereknek (weave, flannel) es service discoveryvel discoveryvel operani (etcd, consul), vagy docker registribol dns-t konfiguralni (docker spy).

"Milyen módon lehetséges szolgáltatás automatikus elindítása? A "systemctl enable sshd" ugye pl. nem használható a docker konténerben." A legegyszerubb modja, hogy keszitesz egy sajat kontenert, es abban vagy a Dockerfile-ban engedelyezed, vagy egy entry pointot adsz meg, es abban inditod el docker run -t my-container:lastest /myentrypoint.sh. Lehet ez igy elsore tulzasnak hangzik, de a docker szemlelet az, hogy egy kontener egy szolgaltatas, azaz, ha ssh-ra meg httpd-re is szukseged van egyazon kontenerben, akkor ott mar el lehet gondolkozni, hogy hogyan lehetne szetvalasztani a kettot (es miert van szukseg ssh-ra?). Ne ertsd felre, van, hogy kell ssh is egy szolgaltatas melle, ez csak az elv. Ha azert kell ssh, mert szeretnel hozzaferest adni a webszerver fajljaihoz usereknek, akkor az lehet egy kulon kontener, hisz a fajlok ugyis valami volumen vannak, a fajl szerver szolgaltatas, meg kulon szolgaltatas. Ha azert kell ssh, hogy tudd managelni a kontenert kezzel, akkor oda lehet nem is kell ssh, hiszen a host geprol docker exec -it bash. Ha azert kell ssh, hogy automatizaltan tudd managelni a kontenert (pl ansible, saltstack), akkor azon erdemes elgondolkozni, hogy miert nem immutable a kontener, miert kell egyaltalan managelni, miert nem eleg a kontenereket managelni. Remelem sikerul mindent osszezavarnom :), de ha kontenerezesre adod a fejed, akkor vannak itt mindenfele elvek, amiket lehet kovetni, es lehet roluk vitatkozni/beszelgetni.

"A "sysctl net.ipv4.conf.all.forwarding" 1-et ad vissza. A centos-on az sshd-t futtatom, de a fedora konténerről nem tudok bessh-zni. Mi hiányozhat?" a Kontenerek kene, hogy lassak egymast, ha ugyanazon a gepen futnak.
-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

Találtam egy mintát:
https://github.com/CentOS/CentOS-Dockerfiles/tree/master/wordpress/centos7

Működik is. Ha a konténerhez csatlakozom (docker attach centos7), akkor lefut a "start.sh".
Viszont nem tudok loginolni. Mit rontok el?

# Dockerfile
FROM centos:centos7
MAINTAINER The CentOS Project

RUN yum -y update; yum clean all
RUN yum -y install epel-release; yum clean all
RUN yum -y install httpd php php-mysql php-gd pwgen supervisor bash-completion openssh-server psmisc tar; yum clean all
ADD ./start.sh /start.sh
ADD ./foreground.sh /etc/apache2/foreground.sh
ADD ./supervisord.conf /etc/supervisord.conf
RUN echo %sudo ALL=NOPASSWD: ALL >> /etc/sudoers
ADD http://wordpress.org/latest.tar.gz /wordpress.tar.gz
RUN tar xvzf /wordpress.tar.gz
RUN mv /wordpress/* /var/www/html/.
RUN chown -R apache:apache /var/www/
RUN chmod 755 /start.sh
RUN chmod 755 /etc/apache2/foreground.sh
RUN mkdir /var/run/sshd

EXPOSE 80
EXPOSE 22

CMD ["/bin/bash", "/start.sh"]

A CMD-ben megadott command lefut (kilép), akkor a konténer is kilép. Értem a logikáját.
Inkább azt csinálom, hogy a Dockerfile-ban:
CMD ["/bin/bash"]

A start.sh-t kézzel futtatom. De még tesztelem.

Az ssh nem működik (connection reset by peer), viszont a httpd, mysql, WP megy.

Az első parancs amit kiadsz kapja az 1-es PID-t. Ha az 1-es processz lefutott a konténer leállítja magát.

Igen, értem. Kösz!
Csak az ssh zavar egy kicsit, hogy miért nem megy. Persze konzolon be lehet lépni...

Minek belépni?

Pl. mivel ez egy fejlesztői környezet, az éppen tesztelt pl. friss php alkalmazást fel kellene tölteni.

Érdekes megközelítés. Miért nem csomagolod bele?
Lehet mr. Henry Fordnak mégiscsak igaza volt: If I had asked people what they wanted, they would have said faster horses.

Próbáld meg más portra tenni az SSH-t (-P kapcsoló autómatikusan megteszi neked). Nem lehet hogy ütközik a host-on futó SSH-val? :P

Ha nem ez a baj akkor az SSH configban lesz valami nem engedve (pl. bárhonnan csatlakozás vagy ilyesmi).

volumekent is csatolhatod lokalis fajrendszerrol

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

Szia!

Nem igazán szokás docker konténerbe ssh-zni, megoldható, de nem ajánlott megoldás. Ha nagyon szeretnél terminált kapni akkor a docker exec -it konténer_id bash parancs kiadásával tudod ezt elérni.

Teszt jelleggel ezt raktam gyorsan össze, ami működik:

# filename: Dockerfile
#
#
# Original:
# https://github.com/CentOS/CentOS-Dockerfiles/tree/master/wordpress/centos7
#

FROM centos:centos7
MAINTAINER CentOS WP demo

RUN yum -y update; yum clean all
RUN yum -y install epel-release; yum clean all
RUN yum -y install mariadb mariadb-server net-tools nmap mc httpd mod_ssl php php-mysql php-gd pwgen supervisor bash-completion openssh-server psmisc tar; yum clean all
ADD ./start.sh /start.sh
ADD ./start_first.sh /start_first.sh
RUN echo %sudo ALL=NOPASSWD: ALL >> /etc/sudoers
ADD http://wordpress.org/latest.tar.gz /wordpress.tar.gz
RUN tar xvzf /wordpress.tar.gz
RUN mv /wordpress/* /var/www/html/.
RUN chown -R apache:apache /var/www/
RUN chmod 755 /start.sh
RUN chmod 755 /start_first.sh
RUN mkdir /var/run/sshd

EXPOSE 80
EXPOSE 22
EXPOSE 443
EXPOSE 3306
EXPOSE 5432

CMD ["/bin/bash"]

# -------------

docker create -p=22 -p=80 -p=3306 -p=5432 --name="centos7" --hostname="centos7" -t -i centos7/wordpress:centos7
docker start centos7
docker attach centos7
# in container:
/start_first.sh &
/start.sh &

# -------------
~$ cat start_first.sh
#!/bin/bash

__check() {
if [ -f /var/www/html/wp-config.php ]; then
exit
fi
}

__create_user() {
# Create a user to SSH into as.
SSH_USERPASS=`pwgen -c -n -1 8`
useradd -G wheel user
echo user:$SSH_USERPASS | chpasswd
echo ssh user password: $SSH_USERPASS
}

__mysql_config() {
# Hack to get MySQL up and running... I need to look into it more.
mysql_install_db
chown -R mysql:mysql /var/lib/mysql
/usr/bin/mysqld_safe &
sleep 10
}

__handle_passwords() {
# Here we generate random passwords (thank you pwgen!). The first two are for mysql users, the last batch for random keys in wp-config.php
WORDPRESS_DB="wordpress"
MYSQL_PASSWORD=`pwgen -c -n -1 12`
WORDPRESS_PASSWORD=`pwgen -c -n -1 12`
# This is so the passwords show up in logs.
echo mysql root password: $MYSQL_PASSWORD
echo wordpress password: $WORDPRESS_PASSWORD
echo $MYSQL_PASSWORD > /mysql-root-pw.txt
echo $WORDPRESS_PASSWORD > /wordpress-db-pw.txt
# There used to be a huge ugly line of sed and cat and pipe and stuff below,
# but thanks to @djfiander's thing at https://gist.github.com/djfiander/6141138
# there isn't now.
sed -e "s/database_name_here/$WORDPRESS_DB/
s/username_here/$WORDPRESS_DB/
s/password_here/$WORDPRESS_PASSWORD/
/'AUTH_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'SECURE_AUTH_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'LOGGED_IN_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'NONCE_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'AUTH_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'SECURE_AUTH_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'LOGGED_IN_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'NONCE_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/" /var/www/html/wp-config-sample.php > /var/www/html/wp-config.php
}

__httpd_perms() {
chown apache:apache /var/www/html/wp-config.php
}

__start_mysql() {
# systemctl start mysqld.service
mysqladmin -u root password $MYSQL_PASSWORD
mysql -uroot -p$MYSQL_PASSWORD -e "CREATE DATABASE wordpress; GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost' IDENTIFIED BY '$WORDPRESS_PASSWORD'; FLUSH PRIVILEGES;"
killall mysqld
sleep 10
}

__run_supervisor() {
supervisord -n
}

# Call all functions
__check
__create_user
__mysql_config
__handle_passwords
__httpd_perms
__start_mysql
__run_supervisor

# -------------
~# cat start.sh
#!/bin/bash

/usr/sbin/sshd -D &
/usr/sbin/httpd &
/usr/bin/mysqld_safe &

Egy apró probléma, hogy az ssh-t hiába teszem át 23-as portra (Dockerfile és konténer sshd_config), a hiba ugyanaz:
"Connection reset by peer"

Köszönet mindenkinek a segítségért!

Anno én is így kezdtem :)

1. a docker nem a legjobb módja egy full stack virtuálgép létrehozásának. Megoldható, csak perverz, nem hatékony, és egy csomó egzotikus hibába futsz (már tapasztaltad is)
2. RUN-t lehetőleg egyszer használj, mert parancsonként épít egy réteget
3. Rendeld össze a host portot a docker porttal, máskülönben random választ egy nem ütközőt: -p 23:22
4. attach helyett jobban kézreáll az exec. Ez egy plusz interaktív shell-t indít, ha kilépsz, nem lép ki a konténer is: docker exec -t -i centos7 /bin/bash
5. az előző pont amúgy teljesen feleslegessé teszi az ssh-t. Eleinte én is mindenbe beleraktam, de leszoktam róla.
6. csinálsz egy interaktív konténert, majd kézigázon futtatod a háttérben. Ne a bash legyen a CMD, hanem ami elindítja a service-eket. A konténer elindítására én a run-t használom -d kapcsolóval. Esetleg ha reboot után is szükséged van rá, akkor a "--restart=always" is hasznos lehet

Köszönöm. Kipórbálom ezeket. :)

expose-nál asszem átmapolja a portot a "docker ps -a"-nál ennek látszódnia kéne valahogy így: 1732 -> 22.
ilyenkor valójában az ssh -nál a parancsot át kell írni: ssh -p 1732 @
Így NAT-olja a konténernek a 22-es portjára.

Ellenőrizni nem tudom,mert nincs Docker a közelemben épp.

Próbálkozom:

$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0958773f3988 centos7/test:centos7 "/start_first.sh" 21 seconds ago Up 13 seconds 443/tcp, 0.0.0.0:2222->22/tcp, 0.0.0.0:32787->80/tcp, 0.0.0.0:32786->3306/tcp, 0.0.0.0:32785->5432/tcp centos7

$ ssh user@localhost -p 2222
Connection closed by ::1

Valamit biztos nincs beállítva az ssh-ban.

A böngészőben a konténer IP címével lehet böngészni. Pl.: http://172.17.0.14 és szépen bejön az apache teszt oldal.

és mi van a start_first.sh-ban? fut egyáltalán sshd process a konténeredben?

Megvan! Az sshd nem generált host key-eket.
Most működik!!! :)

Amúgy egy kicsit overkill-nek érzem a megoldásodat, host gépre ssh és onnan kérsz egy bash-t az image-re amit használni akarsz. Ha 8 image-t futtatsz akkor 8 ssh-t is akarsz?

A hoszt gépről ssh a konténerbe, csak ennyi. Ez pl. a fájlok feltöltéséhez lehet majd jó. Csak ezért van a konténerben ssh.

De a fájlokat eléred a host gépről ssh nélkül is szerintem.

En siman hozza szoktam csapni indulaskor egy konyvtarat, kesobb hasznos adatcserere.

Igen, egyelőre ismerkedem a docker-el. Majd kialakul a végleges megoldás. :)
Köszönöm a segítséget!

AFAIK a docker alap szemlélete az, hogy miután felépítesz egy docker image-et, annak se a konfigurációja, se a tartalmazott fájljai nem változnak utána. Ha valami változik, újra kell építened az image-et, ezért van a Dockerfile, ami tartalmazza az image építéséhez szükséges konfigurációt. Szerintem amit te csinálsz, az ezzel a szemlélettel teljesen szembemegy. Tapasztaltabbak véleménye érdekelne, hogy egyrészt jól tudom-e, másrészt ha igen, fejlesztést hogyan lehet jól megoldani dockerrel.

nagyjabol jol latod, de lehet olyan igeny is, hogy az adatoknak perzisztensnek kell lenniuk. Hekkelesselparancssori opcioval ez is megoldhato.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Egyreszt o meg tanul, nem kell elvarni a szabvanyos Docker hasznalatot meg...

Masreszrol engem is erdekelne a fejlesztesi/uzemeltetesi metodika, foleg olyan webappoknal amik maniakusan irnak a fajlrendszerbe (WP, Drupal, egyeb CMS-ek)
--
Blog | @hron84
Üzemeltető macik

Erre a problémára létezik egy flocker nevű projekt (https://clusterhq.com/), ami már a Docker 1.7-tel experimental pluginként tesztelhető, amivel lehetőség van az adat volumeok mozgatására a docker image-dzsel együtt. Sajnos az 1.8-as Docker release notes-ban nem egyértelmű az utalás nekem a flocker plugin-ra, hogy bekerült volna-e a master ágba. Ami késik nem múlik.

kapcsolt adat konténer vagy becsatolt külső könyvtár

Biztos, hogy neked a Docker-re van szükséged?
A Docker arra való, hogy EGY alkalmazást csomagolj bele az összes beállításával együtt, ezáltal könnyedén mozgatható legyen számítógépek, rendszerek között. Ha virtuálisgép-szerűséget szeretnél, akkor arra nagyon nehéz lesz használni, arra szuper jó megoldás az LXC, mert az arra való. Javaslom nézd meg, nem nehéz használni, pillanatok alatt beüzemelhető, megtanulható.

Docker-t tanulni hasznos. Akkor is ha nyakatekert usecase-ből indulsz ki. Az első alkalommal nehéz elszakadni a virtuálgép fogalmától, megérik majd.

Egy host könyvtárat próbálok bemountolni a konténerbe. Parancssorból meg is teszi, pl.:

docker create -p=80 --name="centos7" --hostname="centos7" -t -i -v /test:/mnt/host centos7/test:centos7

A konténerben tudom is írni az /mnt/host-ot.

A Dockerfile-ban próbáltam megadni:

VOLUME /test:/mnt/host

De ilyenkor a konténerben a /mnt/host üres, nem mountolódik fel.
Hol rontom el?

Ha jól olvasom Dockerfile-ból nem fog működni:
http://docs.docker.com/userguide/dockervolumes/
--------------
Mount a host directory as a data volume

...

"Note: This is not available from a Dockerfile due to the portability and sharing purpose of built images.
The host directory is, by its nature, host-dependent,
so a host directory specified in a Dockerfile probably wouldn’t work on all hosts."
--------------

A Dockerfile fájlban megadott útvonalra a rendszer mountol egy könyvtárat. Pl.:

# Dockerfile
...
VOLUME /mnt/volume-1
...

A "docker inspect < containerid >" kimenete megadja, pl.:

"Volumes": {
"/mnt/volume-1": "/var/lib/docker/volumes/70f0fbeebcd6151ccf7f22f2ab0t0114546020b6864c3cc8b65ed0f51bf24613/_data"
},

(hátha később másnak is hasznos lehet.)

> Hol rontom el?

Ott hogy ez ütközik a Docker koncepciójával. A cél hogy az image amit létrehozol bármely gépen működjön, arra viszont nincs garancia hogy az általad megadott könyvtár létezik a host-on. Csak kézzel tudsz csatolni, Dockerfile-ból nem.

Köszönöm, igen. Közben én is rátaláltam a doksiban.

subs.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Sub szintén.

---------------------------------------
Devmeme - fejlesztői pillanatok

++

+1

subs mégegyszer ... :)
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Sziasztok,

golgota javaslatára belevágtam a dockerbe, de 1 ponton megakadtam.

RUN eleresi_ut/configure --localstatedir=/var --with-database=mysql --enable-starttls --enable-tcpwrappers

"util/gen-iv.pl No such file or directory."

RUN make
pedig "fatal error."

De ha ezt a 2 sort és ami alatta van kitorlom, azaz eddig a pondig buildelem, majd elinditva a kontenert kiadom ue. a 2 parancsot, akkor hiba nélkül sikerül a telepítés.
Ekkor megfoghatnám committal, előbb említett kézi telepítés után, majd forrásként használva tovább építkezhetnék, de én egy robosztus Dockerfilét szeretnék, amiben minden benne van, hogy később könnyebben módosíthassam.

Miért viselkedik így a Docker???

ps.: Érdekes, hogy Dockerfile elején már alkalmaztam a config/make/make install parancsokat egy másik csomagnál, és ott rendben végig is ment.

Nekem ugy tunik az az util es .pl a forrasban kellene legyen amire a configure-t futtatod. Az util nem tunik standard linux utvonalnak.

Amugy ha robusztus dockerimage-t akarsz ott a buildroot. Es hozzacsapod a sajat forditani valodat. Aztan a dockerfileban csak ADD rootfs.tar es kesz.
Nem szokas forditani Dockerfile-ban. Abba csak belerakjuk ami kell. Tehat ha mindenaron buildelni akarsz, akkor csinalsz egy image-t, futtatod, buildelsz benne, commitolsz. Attol ugyanolyan robusztus lesz.

hacsak nincs egy kontener build-re :-) En legalabbis azzal gyartok csomagokat.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

a configure script nem passzol a forras tobbi reszehez: a configure a util/gen-iv.pl-t keresi, de azt mar egy ideje kidobtam a forrasbol. Toltsd le a master branch-et, es probald ujra, de mar a --enable-starttls --enable-tcpwrappers nelkul, mert azok mar default feature-ok.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

golgota köszi, amíg bírom próbálkozok, aztán ha nem megy, majd az utolsó gondolatodat követem

sj köszi, letöltöttem, kibontottam.
/config már jó, a make kimenete:

jsuto-piler-78892cdac981/src/dirs.c:13:19: fatal error: piler.h: No such file or directory
#include
compilation terminated.

valami nagyon nem jo. Tedd mar fel pastebin-re a make teljes kimenetet. Ill. milyen image-bol keszult kontenerben dolgozol?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Hát az elég rövidke, de tessék:
http://pastebin.com/embed_js/eJx8nPe4

FROM debian:8.5

ez a problema: -c ../jsuto-piler-78892cdac981/src/dirs.c

Mutasd meg a Dockerfile-t is, mert azt kell fixalni.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Elég csúnya, remélem golgota nem nézi :) de addig a pontig megy.

pastebin.com/embed_js/XsyhGFVc

RUN jsuto-piler-78892cdac981/configure --localstatedir=/var --with-database=mysql
RUN make
RUN su -c \'make install\'

helyett:

RUN cd jsuto-piler-78892cdac981 && ./configure --localstatedir=/var --with-database=mysql && make clean all install

probaljuk meg igy is

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Eppen irni akartam hogy probaljuk meg kulon layerek nelkul, egyetlen layerben. Mivel a ket RUN ket kulon layerben fut, igy a masodikban kiadott make elofordulhat hogy azt sem tudja mit kellene make-elnie.

Köszönöm, így mindjárt más.
Az utolsó sorban (29.) lemaradt egy "d", eddig tartott, mire megtaláltam a hibát :) de sikerült :D
Szóval minden ok, már csak a make postinstallnak hogyan lehet átadni a paramétereket?

interaktivan. Egy docker image-et azonban nem igy allitunk ossze. Egy lehetoseg, hogy ha mar minden fenn van, akkor belepsz docker exec-kel a kontenerbe, es kezzel kiadod a make postinstall-t, majd a modositasokat commit-olod (docker commit). Pro megoldas: a szukseges konfig file-okat eloallitod, majd az ADD direktivaval beleegeted az image-be. En legalabbis igy csinalom a docker-be deploy es tesztek soran.

En 2 fazisban keszitem el az image-et: 1. a szukseges csomagok telepitese, 2. piler deploy. Alabb 2 pastebin az inspiraciohoz: http://pastebin.com/Yxfjxy15 es http://pastebin.com/VTSWu38W

Az eredmeny pedig egy kb. immutable image. Par dolgon ugyan lehet valtoztatni/javitani real-world deploy eseten, de tesztelesre pont jo.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

+1
Image keszitesekor nem buildelunk. Hozzaadunk kesz dolgokat.
Ezert is ajanlottam a buildroot/fakeroot/barmi-t amit aztan tarolunk es csak annyit irunk a Dockerfile-ba, hogy ADD root.tar. Es kesz is az image, plusz a jatek az entrypointtal, supervisord-vel vagy ami tetszik.
Ha buildelni kell, akkor azt mar containerben es commit.

nekem van egy kulon kontenerem/image-em a build-re, ami eloallitja a kesz artifact-okat, amelyeket majd a deploy-nal felhasznalok.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"kezzel kiadod a make postinstall-t" ezzel evesz a docker egyik lenyege, megpedig a reprodukalhatosag, es automatizalt buildet sem lehet hozza csinalni.
"majd a modositasokat commit-olod (docker commit)" jol meg kell fontolni mi a cel. A commit letrehoz egy reteget a filerendszerben. Aminek van egy elonye, hogy ha ujat inditasz onnan fogja folytatni, azon az egy gepen. Ha pusholod is valami repoba, akkor mas gepeken is, csak fel kell kotni a gatyat, hogy kideritsd kesobb abban a retegben mi tortent, igy azt felhasznalva (esetleg mas kontenerekhez) ugrik a history. A docker kontenereknek az is a szepsege, hogy lehet tudni mi a fene van benne, egeszen addig, valami adatot nem general bele, ami nem szep.

Kontenert automatizaltan szokas buildelni, hogy a vegeredmeny reprodukalhato legyen, illik megtartani a historyt, mert ellenkezoleg az ujrafelhasznalhatosag serul. A Dockerfile-ban minden parancs egy uj reteg, szoval minden parancs vegen a "cleanup"nak is ott erdemes lennie (apt-get install vim && apt-get clean). Egy kontener egy dolgot csinal (ezt nem lehet kobevesni sajnos, de torekedni kell ra). Eles kornyezetben a futo kontenernek immutable kell lennie, ha disk iras tortenik erdemes kideriteni mi okozta (nem-e fogja beteliteni a root disket), es hogyan lehet megszuntetni. A cel, ha megpusztul a kontener egy masikra barmikor lecserelheto legyen.

Persze ha a docker "csak" egy dev tool, akkor ott barmit lehet :D

-
Big Data trendek 2016