Fórum Root.cz
Hlavní témata => Server => Téma založeno: harrison314 09. 07. 2018, 18:59:53
-
Hladam sposob ako jednoducho deployovat nove verzie webobych palikacii na linux servery (ubuntu, centos).
Pochadzam z Windows sveta, kde je na to Web Deploy.
Momentalna situacia je taka:
- Vyvojari vyrvoria novy balicek z apliaciu (zip subor zo spustitelnou aplikaciu)
- Admin si ho stiahne k sebe.
- Zastavi systemd sluzbu danej webovej apliacie.
- Nahra nove subory aplikacie na server a pri tom dava pozor aby si neprepisal nezalohovane konfigy.
- Admin spusti sluzbu a dufa, ze znovu nabehne.
Ako zacat z automatizaciou tohto procesu vramci Ci/Di, nejde mi teraz ani o to ako veci buildovat, ide mi o to co pouzit na nasadenie aplikacie na sever.
Ake programy alebo nastroje sa pouzivaju na strane produkcneho serveru aby slo aplikaciu nasadit automaticky napriklad pouzitim jej postnutim cez HTTP (ako to ma Azure pomocou Kudu), alebo inak, proste nieco na co viem napojit ine nastroje.
Aj je daco nejasne pytajte sa.
-
Kubernates + integrace do libovolneho CI
-
Zabudol som dodat, ze na deploy a prveadzku sa nesmie pouzit Docker ani ina kontainerizacna technologia (to je na tom tazke).
-
puppet nebo jakykoliv jiny automate tool.
-
Zabudol som dodat, ze na deploy a prveadzku sa nesmie pouzit Docker ani ina kontainerizacna technologia (to je na tom tazke).
To je dost ... pitomy omezeni :-)
Jak uz tu psal Jose, puppet je urcite dobra volba.
Ale stejne tak to asi muzes zautomatizovat i treba pomoci obycejneho Jenkinse a SSH pluginu, prip. spustit Jenkins slave na tom danem stroji.
Ale je to uplne jiny pristup / architektura nez jakou ma Web Deploy
-
- Oddělí se konfigurace od samotné aplikace, aby nebylo při instalaci nové verze dávat pozor, aby se něco nepřepsalo.
- Aplikace se rozbaluje do nového umístění (původní služba stále běží).
- Aplikace se přehodí do nového umístění
Ten třetí krok záleží na konkrétním způsobu fungování aplikace – pokud běží pod webovým serverem, který pouze servíruje soubory z disku (třeba PHP aplikace nebo statický web), stačí web serveru změnit symlink na kořenový adresář aplikace. Pokud má ta aplikace integrovaný web server a umí spolupracovat se socketovou aktivací systemd, dá se použít k bezvýpadkové změně to. Jinak je pro co nejkratší výpadek potřeba spolupráce aplikace, aby si uměla prohodit port se starou verzí. A pokud krátký výpadek nevadí, tak se prostě zastaví stará verze služby a pak nastartuje nová verze.
Puppet, Kubernetes, Ansible, distribuční balíčkovací nástroje a další mají smysl tehdy, pokud tím chcete spravovat víc aplikací, nebo vám ta aplikace běží v několika instancích. Pokud ta aplikace běží na jednom serveru, stačí shell skripty – bylo by pracnější starat se o ty automatizační nástroje než o tu samotnou aplikaci.
-
Nevím, zda je to "systémové", ale u systémů, které se nikam nedistribuují a provozujeme si je sami (či já sám v případě domácích projektů), se mi vždycky osvědčilo verzovat i konfigy minimálně pro cílový stroj a před nasazením je deploy skriptem symlinkovat do finálních cest/názvý souborů.
Vygeneruje se app-cadidate, shodí aktuální verze app-current, přesune do app-previous, app-candidate se přesune (rychlý mv) do app-current, spustí, hodí se základní test, že to běží a když ten neprojde, shodí se, přesune se do app-failed-datum, vratí app-previous -> app-current a nastartuje. Tenhle deploy dělá skript, je to triviální, žádná věda. Nepoužíváme kontejnery, vše je v jednom adresáři.
app-failed-datum je pak čas prozkoumat, proč se deploy nepovedl. V app je samozřejmě soubor s informací o head commitu buildu.
-
Zabudol som dodat, ze na deploy a prveadzku sa nesmie pouzit Docker ani ina kontainerizacna technologia (to je na tom tazke).
To je dost ... pitomy omezeni :-)
Jak uz tu psal Jose, puppet je urcite dobra volba.
Problem je, ze robim vo vysoko secure prostredi, siete zo servermi a z gitlabom sa navzajom nevidia, kontainer je v podstate nadavka, sambu a sietove disky pouzit nemozem, v podstate nic co saha na system, plus dane stroje su v DMZ a nemaju pristup k internetu.
Pre to som dufal v nieco ako Web Deploy alebo Kudu, kde by som to proste na dany endpoint deployol cez HTTPS.
- Oddělí se konfigurace od samotné aplikace, aby nebylo při instalaci nové verze dávat pozor, aby se něco nepřepsalo.
- Aplikace se rozbaluje do nového umístění (původní služba stále běží).
- Aplikace se přehodí do nového umístění
1. Krok jedna uz je zvladnuty davno, ale ked to nasadzujes rucne nehody sa stanu aj tak, preto chcem ten ludsky faktor vytlacit.
Tu mam problem s krokom 3, je to samsostane beziaca aplikacia, ziadne skripty, ktora bezi na danom porte a ten nejde prehodit pocas behu.
-
Shodíš, přesuneš, nahodíš v původním místě se stejným portem. Stejně to musíš shodit. Co na tom nejde?
-
Tu mam problem s krokom 3, je to samsostane beziaca aplikacia, ziadne skripty, ktora bezi na danom porte a ten nejde prehodit pocas behu.
Tento krok moze znamenat tolko, ze presmerujes symbolicky odkaz. To co by si chcel urobit sa systemovo da, pozri sa ako to riesia napr tu https://github.com/rcrowley/goagain.
Jednoduche riesenie je ale bindnut na localhost a nejaky vhodny port, pred to sa da reverse proxy (napr nginx). Potom co nahodis novu apku a vsetko je ok (test napr cez healthcheck url), zmenis port v nginx na novu verziu a reloadnes config. Ma to zopar hacikov a obmedzeni, ale je to asi najjednoduchsie riesenie.
-
Hele a co od toho cekas? Ty resis atomovku, a pritom chces mozna jen trikolku ...
1) muzes pouzit standardni balickovac dotycnyho distra, tzn vyrobit si prislusnej balicek (a kazdy jedno distro umi pridat privatni repo, takze to muzes mit i centralne distribuovany)
2) muzes proste napsat par radku v bashi
...
milion dalsich moznosti
Vse zavisi jen na tom, co od toho chces, a to si tu nenapsal. Pokud ti jde jen o to, ze potrebujes vymenit A za B a restart sluzby nevadi, tak na to nepotrebujes vubec nic, jen tech par radku scriptu. Normalne to stopnes, vymenis a nastartujes.
Pokud potrebujes aby to bylo bez vypadku, musi to podporovat i ta tvoje aplikace. Trebas SSH restartnes pripojenej na to sshcko, a ani te neodpoji, narozdil od widlordp. Jednoduse pro aktivni sessions zustava bezet puvodni aplikace, ale uz neposloucha na portu pro nove prichozi.
-
Jj, vymysli si najprv co chces mat ako konecny stav a nie ze nieco nejako. Ked napises, ze nema ten server nikde pristup a je to high secure prostredie, tak neviem ci tu je vobec co riesit. Ten admin to robi rucne asi z nejakeho dovodu.
-
Tu mam problem s krokom 3, je to samsostane beziaca aplikacia, ziadne skripty, ktora bezi na danom porte a ten nejde prehodit pocas behu.
Udělal bych na to jednoduchý skript, který rozbalí noovu verzi do nového adresáře, zastaví službu, přehodí symlink na novou verzi a službu nastartuje.
#!/bin/sh
set -e
cd "$(dirname "$0")"
VERSION=`cat upload/version.txt`
mkdir /opt/server/$VERSION
unzip -q upload/server-$VERSION.zip -d /opt/server/$VERSION
sudo systemctl stop server.service
ln -sn --backup=simple $VERSION /opt/server/current
sudo systemctl start server.service
-
Ansible, vlastní skript nebo něco hotového (třeba https://github.com/ansistrano/deploy). Na serveru je potřeba mít nainstalovaný python. Má to čitelnější výstup než shell skript, výsledek bude podobný.
-
Hele a co od toho cekas? Ty resis atomovku, a pritom chces mozna jen trikolku ...
Skumam ake mam moznosti.
Rad by som sa vyhol custom skriptom (treba ich pisat, odladovat a udrzovat) na druhej strane by som sa aj rad vyhol riesniam ako Pupet, lebo mi to pride ako kanon na vrabce.
Proste zistujem ake su moznosti a co sa pouziva inde.
Co sa tyka resrtu sluzbu, tak ten je potrebny a v sucastnosti vypadok sluzby pre zakaznika na par minut nevadi, no rad by som sa dostal do stavu, kedy by zakaznik vypadok sluzby ani nezaznamenal.
-
Rad by som sa vyhol custom skriptom (treba ich pisat, odladovat a udrzovat)
To ale budete muset dělat vždy, protože máte nějakou svou aplikaci, takže nějak musíte popsat, jak se má nasadit. Jestli to budete popisovat skriptem nebo nějakou konfigurací je už vedlejší. Ostatně pokud nasazení spočívá jen v rozbalení zipu, ten skript je triviální.
-
My u podobnyho omezeni delali standardni RPM balicky a zaradili jej do repozitare. Cron job na serveru pak updatnul balicek a podle potreby restartnul http server a nekdy i databazi. To zaviselo od upgrade scriptu v tom balicku. V pripade problemu pak stacilo nahodit starsi balicek a restornout DB zalohu. Emergence release byla obdobna akorat to neslo cronem ale novy RPM balicek se nahodil rucne.
-
Rad by som sa vyhol custom skriptom (treba ich pisat, odladovat a udrzovat) na druhej strane by som sa aj rad vyhol riesniam ako Pupet, lebo mi to pride ako kanon na vrabce.
Když vyloučíš obě poloviny řešení, tak už ti nic nezbude :-)
Ten skript je triviální a rovnou si jej verzuj s aplikací, ať je to všechno pohromadě. Osvědčilo se nám rozdělit jej na dva -
1) update skript řeší zda nasadit novou verzi. V našem případě porovnává commit s tagem OK remote vs. lokálně - pokud se tag posunul, je v remote repozitáři nová verze a má se nasadit. Máme to takto automatické, protože se spouští v noci. Skript jen stáhne (příp. rozbalí novou verzi). Update skript je dobré mít co nejmenší, protože běží vždy se zpožděním jednoho update cyklu (spouští se skript z verze předchozí), tudíž chceš něco, do čeho nebudeš dělat často změny.
2) build/deploy skript - ten se spouští již z nové verze a může obsahovat změny vyžadované aktuální verzí.
Opět žádná věda.
-
Rad by som sa vyhol custom skriptom (treba ich pisat, odladovat a udrzovat)
To ale budete muset dělat vždy, protože máte nějakou svou aplikaci, takže nějak musíte popsat, jak se má nasadit. Jestli to budete popisovat skriptem nebo nějakou konfigurací je už vedlejší. Ostatně pokud nasazení spočívá jen v rozbalení zipu, ten skript je triviální.
Ano, ale dufal som v nieco comu mozem doverovat viac ako bashu, prosto daco co uz ma vyrienie logovanie, prava, backup a podobne.
Rad by som sa vyhol custom skriptom (treba ich pisat, odladovat a udrzovat) na druhej strane by som sa aj rad vyhol riesniam ako Pupet, lebo mi to pride ako kanon na vrabce.
Když vyloučíš obě poloviny řešení, tak už ti nic nezbude :-)
Dufal som, ze v strede sa este nachadza nieco medzi, napriklad ako je Cake pre buildovanie (ked si to clovek porovna z bat skriptami je to rozdiel).
Co sa taky skriptov, viem, ze to az taka veda nie je, no mam pocit, ze je to malo robusne rienie.
V kazdom pripade dakujem za napady, ak o niecom este viete kludne dajte vediet.
-
Obecne v praxi vidim, ze kdo se nechce naucit puppet,pouziva Ansible.
-
....
Custom script pro custom aplikaci stejne budes muset napsat a "udrzovat" (nevim co se udrzuje na rozbaleni archivu nekam, a pripadne prehozeni toho simlinku), protoze zadnej nastroj tu tvoji aplikaci nezna. Takze mu stejne nejak (tim scriptem) musis rict, co kde a kam ma dat, pripadne co dalsiho s tim ma udelat.
A ten "script" muze vypadat ruzne - muze to byt nejaky XML, muze to byt kus bashe, muze to byt klidne nejaka samostatna binarka ...
Ale vzdyky je nejjednodussi pouzit to, co v systemu mas, protoze kazda dalsi vec = dalsi vec co je treba udrzovat, dalsi vec co se muze rozbit. V kazdym tuxovi mas bash, takze pobud nepotrebujes spravovat stovky serveru, je to nejjednodussi(a taky zdaleka nejspolehlivejsi) mozna vec kterou muzes pouzit.
Vypadek je pak danej defakto vyhradne casem, za kterej se ti ta servisa ukonci a znova nastartuje, mezi tim je prakticky presne 0. V zavislosti na klientovi (=klientska aplikace) a rychlosti toho restartu nemusi aplikace ani poznat, ze se neco stalo. Pro uzivatele se to mozna zachova jako trochu delsi reakce v okamzik restartu.
-
Konfigy
- dat pod git control, tj. muzes revertovat verze on the fly, do aplikace integrujes napr. Spring Cloud Config, ktery umi reloadovat sluzbu kdyz se zmeni konfigurace (git pull commit -blabla)
Deploy
Mozna by pomohl Maven Deploy plugin, nebo jestli to bezi na tomcatu, tak muzes napr. pouzit tomcat deploy plugin, nebo to je springboot sluzba v tom zipu, nebo to je obsah warka?
Napr. tomcat plugin:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<url>http://localhost:8080/manager/text</url>
<server>TomcatServer</server>
<path>/myapp</path>
</configuration>
</plugin>
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
Ne, jen javaman.
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
V Javě jsem nikdy nedělal, ale umím pochopit psaný text: "jestli to bezi na tomcatu"
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
V Javě jsem nikdy nedělal, ale umím pochopit psaný text: "jestli to bezi na tomcatu"
Tak:
1. V dotazu není o Javě ani zmínka, přesto je nabízen Maven/Tomcat jako velice specifické řešení, nic univerzálního
2. To jste vytrhl z kontextu, ten Tomcat se vztahuje na konkrétní ukázku konfigurace, předtím nabízí Maven deploy plugin nebo springboot
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
Jestli se nepletu tak harrison ma account i na devel.cz a je to Javista :-) prosim uzivatele o potvrzeni, jestli se pletu.
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
Jestli se nepletu tak harrison ma account i na devel.cz a je to Javista :-) prosim uzivatele o potvrzeni, jestli se pletu.
Resp. vetsinou keca do Javy i .NET, ale deployjuje na Ubuntu, takze uznavam, ze slepe dedukuju, ze pujde o Javu. Nebo jede uz .NET plne na Linuxu? Ale tak sorry no :-)))
Harisi, v cem je ta aplikace napsana?
-
Resp. vetsinou keca do Javy i .NET, ale deployjuje na Ubuntu, takze uznavam, ze slepe dedukuju, ze pujde o Javu. Nebo jede uz .NET plne na Linuxu?
.NET Core ano a docela dobre :-) Ale zatim se to moc nepouziva jeste, je to pomerne nova technologie.
1. V dotazu není o Javě ani zmínka, přesto je nabízen Maven/Tomcat jako velice specifické řešení, nic univerzálního
2. To jste vytrhl z kontextu, ten Tomcat se vztahuje na konkrétní ukázku konfigurace, předtím nabízí Maven deploy plugin nebo springboot
No, hezky, az na takovy drobny detail, ze ten maven deploy plugin univerzalni je. Neni tim problem treba deployovat PHP nebo React aplikaci, ci cokoliv jineho, protoze Deploy plugin resi prenos artifaktu a absolutne neresi co za artifkat to je.
A svete div se, ono se to obcas pouziva i na jine veci nez je Java - treba kvuli nativni integraci Mavenu v Jenkinsu.
-
Jsou všichni Javisté tak omezení, že si myslí, že na světě je jen Java?
Jestli se nepletu tak harrison ma account i na devel.cz a je to Javista :-) prosim uzivatele o potvrzeni, jestli se pletu.
Resp. vetsinou keca do Javy i .NET, ale deployjuje na Ubuntu, takze uznavam, ze slepe dedukuju, ze pujde o Javu. Nebo jede uz .NET plne na Linuxu? Ale tak sorry no :-)))
Harisi, v cem je ta aplikace napsana?
Harrison jede na .NETu a kde se dá, tak .NET Core. :)
-
Harrison jede na .NETu a kde se dá, tak .NET Core. :)
Tak to nepouzit na deployment v tom pripade docker je velka skoda, vzdyt to ma i oficialni, podporovane, images :-)
-
Dane aplikacie co potrebujem su v .Net Core (weby a REST-ove sluzby), ale vramci firmy su to aj nejake aplikacie napisane v C++.
No primarne .Net Core a ten sa na linuxe demonizuje ako nativna aplikacia, preto som sa pytal na ne, plus tie apky co nasadzujeme u seba su pisane ako 12 faktorove aplikacie (viac ci menej).
.NET Core ano a docela dobre :-) Ale zatim se to moc nepouziva jeste, je to pomerne nova technologie.
Praveze pouziva, mame to uz dva roky v prudukcii a maximalna spokojnost, plus co robia znami vo firmach, tak ti webovy tiez prechazdaju na .Net Core.
Ano, keby mozem pouzit docker v produkcii, tak to by mi velmi pomohlo, prakticky vysteky navody od buildu, CI, DI az po nasadenie su pre Docker, potom Azure a AWS, preto sa pytam tu.
-
1. V dotazu není o Javě ani zmínka, přesto je nabízen Maven/Tomcat jako velice specifické řešení, nic univerzálního
2. To jste vytrhl z kontextu, ten Tomcat se vztahuje na konkrétní ukázku konfigurace, předtím nabízí Maven deploy plugin nebo springboot
No, hezky, az na takovy drobny detail, ze ten maven deploy plugin univerzalni je. Neni tim problem treba deployovat PHP nebo React aplikaci, ci cokoliv jineho, protoze Deploy plugin resi prenos artifaktu a absolutne neresi co za artifkat to je.
A svete div se, ono se to obcas pouziva i na jine veci nez je Java - treba kvuli nativni integraci Mavenu v Jenkinsu.
Nic proti, ale jen jsi potvrdil, co jsem dříve psal. To, že je to univerzální, je celkem logické, kdyby to nebylo univerzální, tak by to dnes dost dobře nemohlo fungovat. Ono světe div se, v podstatě všechny platformní deployment systémy umí deployovat cokoliv. Problém je to, že pokud nepoužívám Javu, nebudu se kvůli deploymentu učit Maven a jeho pluginy. Kdybych ti na deployment jaru doporučoval Capistrano, taky by ses na mně díval jak na blázna. A taky mají hned na titulní stránce napsáno "for any language". A budeš se divit, naučit se to Capistrano je jednodušší než ten Maven. :)
-
Dane aplikacie co potrebujem su v .Net Core (weby a REST-ove sluzby), ale vramci firmy su to aj nejake aplikacie napisane v C++.
No primarne .Net Core a ten sa na linuxe demonizuje ako nativna aplikacia, preto som sa pytal na ne, plus tie apky co nasadzujeme u seba su pisane ako 12 faktorove aplikacie (viac ci menej).
Hm, zajimave, ja jsem opustil net zejmena kvuli opusteni windows platformy cca 10 let zpatky a presel jsem na javu, ale core vypada zajimave no. Nasel jsem tenhle link, ze to jde ve visual studiu, otazka je, jestli to krome azure podporuje i regular nasazeni na nejaky:
https://github.com/Microsoft/code-challenges/tree/master/Labs/Continuous%20Deployment%20of%20ASP.NET%20Core%20Websites%20to%20Azure%20with%20VSTS
Asi bych dal sanci i Travis CI, nebo Gitlab CI:
https://medium.com/@pjbgf/configuring-ci-for-net-core-using-travis-ci-and-xunit-cc0f809df4fb
-
1. V dotazu není o Javě ani zmínka, přesto je nabízen Maven/Tomcat jako velice specifické řešení, nic univerzálního
2. To jste vytrhl z kontextu, ten Tomcat se vztahuje na konkrétní ukázku konfigurace, předtím nabízí Maven deploy plugin nebo springboot
No, hezky, az na takovy drobny detail, ze ten maven deploy plugin univerzalni je. Neni tim problem treba deployovat PHP nebo React aplikaci, ci cokoliv jineho, protoze Deploy plugin resi prenos artifaktu a absolutne neresi co za artifkat to je.
A svete div se, ono se to obcas pouziva i na jine veci nez je Java - treba kvuli nativni integraci Mavenu v Jenkinsu.
Nic proti, ale jen jsi potvrdil, co jsem dříve psal. To, že je to univerzální, je celkem logické, kdyby to nebylo univerzální, tak by to dnes dost dobře nemohlo fungovat. Ono světe div se, v podstatě všechny platformní deployment systémy umí deployovat cokoliv. Problém je to, že pokud nepoužívám Javu, nebudu se kvůli deploymentu učit Maven a jeho pluginy. Kdybych ti na deployment jaru doporučoval Capistrano, taky by ses na mně díval jak na blázna. A taky mají hned na titulní stránce napsáno "for any language". A budeš se divit, naučit se to Capistrano je jednodušší než ten Maven. :)
Nic proti, ale ty pises, jednou, ze to neni univerzalni a podruhe pises, ze je logicke, ze to univerzalni je... a ja nic nevytrhavam z kontextu.
Dale jsem nasel .NET Core Maven Plugin, ale nevim, jak je stabilni a jestli umi vsechno, co potrebujes :-)))
https://github.com/nicodewet/dotnet-maven-plugin
Maven a .NET Core are friends :D
Kazdopadne sem harrisone postni, jak si to nakonec vyresil.
-
Dane aplikacie co potrebujem su v .Net Core (weby a REST-ove sluzby), ale vramci firmy su to aj nejake aplikacie napisane v C++.
No primarne .Net Core a ten sa na linuxe demonizuje ako nativna aplikacia, preto som sa pytal na ne, plus tie apky co nasadzujeme u seba su pisane ako 12 faktorove aplikacie (viac ci menej).
Hm, zajimave, ja jsem opustil net zejmena kvuli opusteni windows platformy cca 10 let zpatky a presel jsem na javu, ale core vypada zajimave no. Nasel jsem tenhle link, ze to jde ve visual studiu, otazka je, jestli to krome azure podporuje i regular nasazeni na nejaky:
https://github.com/Microsoft/code-challenges/tree/master/Labs/Continuous%20Deployment%20of%20ASP.NET%20Core%20Websites%20to%20Azure%20with%20VSTS
Asi bych dal sanci i Travis CI, nebo Gitlab CI:
https://medium.com/@pjbgf/configuring-ci-for-net-core-using-travis-ci-and-xunit-cc0f809df4fb
Prve je Azure (Kudu) a druhe je len build a testovanie. Nic s toho nepomoze na onpremis.
Dale jsem nasel .NET Core Maven Plugin, ale nevim, jak je stabilni a jestli umi vsechno, co potrebujes :-)))
https://github.com/nicodewet/dotnet-maven-plugin
To je sice pekne, ale kvoli tomu nebudem zavadzat do infrastruktury javu.
Dam vediet co nakoniec nie ze fungovalo, ale uzniesol sa konsenzus medzi adminmi, security a devom. To je tak na dva tri mesiace.
-
Z kazdyho buildu udelat rovnou RPM/DPG/whatever a deployovat to pomoci puppet+hiera/ENC, kde jenom zmenis v parametru verzi. Konfiguraky spravovany puppetem, v RPM budou s %config(noreplace). Nejjednodussi puppet manifest by vypadal asi nejak takhle:
file { "konfigurak":
ensure => file,
content => template("cesta_k_erb"),
}
package { "nazev-rpmka":
ensure => "${hiera_promenna_s_verzi}",
require => File["konfigurak"],
notify => Service["tomcat"],
}