slovak translation of 9 pages

content/sk/admin-processes.md

@@ -1,14 +1,14 @@
-## XII. Admin processes
-### Run admin/management tasks as one-off processes
+## XII. Admin procesy
+### Spúštanie administrátorských/správcovských úloh ako jednorazových procesov
 
-The [process formation](./concurrency) is the array of processes that are used to do the app's regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as:
+[Process formation](./concurrency) je sada procesov, ktoré tvoria bežnú prevádzku aplikácie (napríklad odpovedanie na požiadavky). Na rozdiel od toho, vývojári často chcú spraviť jednorazové administratívne alebo údržbové úlohy, ako napríklad:
 
-* Running database migrations (e.g. `manage.py migrate` in Django, `rake db:migrate` in Rails).
-* Running a console (also known as a [REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) shell) to run arbitrary code or inspect the app's models against the live database. Most languages provide a REPL by running the interpreter without any arguments (e.g. `python` or `perl`) or in some cases have a separate command (e.g. `irb` for Ruby, `rails console` for Rails).
-* Running one-time scripts committed into the app's repo (e.g. `php scripts/fix_bad_records.php`).
+* Spustenie databázovej migrácie (e.g. `manage.py migrate` v Django, `rake db:migrate` v Rails).
+* Spustenie konzoly (alebo tiež [REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) shell) aby mohli spúštať ľubovoľný kód alebo skúmať modely aplikácie voči živej databáze. Väčšina jazykov poskytuje REPL spustením interpretra bez argumentov (napr. `python` alebo `perl`) v niektorých prípadoch majú samostatný príkaz (napr. `irb` pre Ruby, `rails console` pre Rails).
+* Spustenie jednorazových skriptov uložených v repozitári aplikácie (napr.. `php scripts/fix_bad_records.php`).
 
-One-off admin processes should be run in an identical environment as the regular [long-running processes](./processes) of the app. They run against a [release](./build-release-run), using the same [codebase](./codebase) and [config](./config) as any process run against that release. Admin code must ship with application code to avoid synchronization issues.
+Jednorazové administračné procesy by sa mali spúštať v identickom prostredí ako bežné dlho [bežiace procesy](./processes) aplikácie. Bežia voči [releasu](./build-release-run), použitím rovnakého [kódu](./codebase) a [konfigurácie](./config) ako ostatné procesy bežiace v rámci releasu. Administračný kód sa musí dodať spolu s kódom aplikácie, aby sa zamedzilo synchronizačným problémom.
 
-The same [dependency isolation](./dependencies) techniques should be used on all process types. For example, if the Ruby web process uses the command `bundle exec thin start`, then a database migration should use `bundle exec rake db:migrate`. Likewise, a Python program using Virtualenv should use the vendored `bin/python` for running both the Tornado webserver and any `manage.py` admin processes.
+Rovnaká technika [izolácie závislostí](./dependencies) by sa mala použiť pre všetky typy procesov. Napríklad, ak Ruby webový proces používa príkaz `bundle exec thin start`, potom databázová migrácia by mala používať `bundle exec rake db:migrate`. A podobne Python program používajúci Virtualenv by mal používať `bin/python` rovnako na spúšťania Tornado webservera aj všetkých `manage.py` administračných procesov.
 
-Twelve-factor strongly favors languages which provide a REPL shell out of the box, and which make it easy to run one-off scripts. In a local deploy, developers invoke one-off admin processes by a direct shell command inside the app's checkout directory. In a production deploy, developers can use ssh or other remote command execution mechanism provided by that deploy's execution environment to run such a process.
+Dvanásť faktorová aplikácia silne preferuje jazyky, ktoré poskytujú REPL shell už v základe, a ktoré jednoducho umožňujú spúštanie jednorazových skriptov. Vývojári na lokálnom nasadení spúšťajú jednorazové administračné procesy priamym shell príkazom v priečinku aplikácie. V produkčnom nasadení môžu vývojári použiť ssh alebo iný spôsob vzdialeného spúšťania príkazov, ktorý poskytuje dané exekučné prostredie na spustenie takého procesu.

content/sk/build-release-run.md

@@ -1,19 +1,19 @@
 ## V. Build, release, run
-### Strictly separate build and run stages
+### Jasne oddelené fázy build, release a run
 
-A [codebase](./codebase) is transformed into a (non-development) deploy through three stages:
+[Kód](./codebase) sa transformuje do (nevývojárskeho) nasadenia troma krokmi:
 
-* The *build stage* is a transform which converts a code repo into an executable bundle known as a *build*. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors [dependencies](./dependencies) and compiles binaries and assets.
-* The *release stage* takes the build produced by the build stage and combines it with the deploy's current [config](./config). The resulting *release* contains both the build and the config and is ready for immediate execution in the execution environment.
-* The *run stage* (also known as "runtime") runs the app in the execution environment, by launching some set of the app's [processes](./processes) against a selected release.
+* *Krok build* transformuje kód v repozitári na vykonateľný balík nazývaný *build*. Použitím verzie kódu v čase commitu špecifikovaného nasadzovacím procesom, krok build stiahne [závislosti](./dependencies) a skompiluje binárky a assets.
+* *Krok release* zoberie build vytvorený predchádzajúcim krokom a skombinuje ho s aktuálnou [konfiguráciou](./config) pre dané nasadenie. Výsledok *release* obsahuje build a konfiguráciu pripravené na okamžité vykonanie v exekučnom prostredí.
+* *Krok run* (alebo "runtime") spustí aplikáciu v exekučnom prostredí naštartovaním aplikačných [procesov](./processes) voči danému release.
 
-![Code becomes a build, which is combined with config to create a release.](/images/release.png)
+![Kód sa stane buildom, ktorý sa skombinuje s konfiguráciou a vytvorí sa release.](/images/release.png)
 
-**The twelve-factor app uses strict separation between the build, release, and run stages.** For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage.
+**Dvanásť faktorová aplikácia striktne oddeľuje fázy build, release a run.** Napríklad: je nemožné spraviť zmeny v kóde počas jeho behu, keďže neexistuje spôsob, ako by sa tieto zmeny dostali späť do fázy build.
 
-Deployment tools typically offer release management tools, most notably the ability to roll back to a previous release. For example, the [Capistrano](https://github.com/capistrano/capistrano/wiki) deployment tool stores releases in a subdirectory named `releases`, where the current release is a symlink to the current release directory. Its `rollback` command makes it easy to quickly roll back to a previous release.
+Nástroje na nasadzovanie zvyčajne ponúkajú spôsoby na správu release, hlavne teda možnosť vrátiť sa na predchádzajúci release. Napríklad [Capistrano](https://github.com/capistrano/capistrano/wiki) si ukladá release v podpriečinku s názvom `releases`, kde je aktuálny release symlink na priečinok s aktuálnym releasom. Tento príkaz `rollback` umožňuje jednoducho a rýchlo vrátiť sa na predchádzajúci release.
 
-Every release should always have a unique release ID, such as a timestamp of the release (such as `2011-04-06-20:32:17`) or an incrementing number (such as `v100`). Releases are an append-only ledger and a release cannot be mutated once it is created. Any change must create a new release.
+Každý release by mal vždy mať unikátne release ID, ako napríklad timestamp release (napríklad `2019-04-06-20:32:17`) alebo inkrementálne číslo (napr. `v100`). Releasy sú záznamy, ktoré iba pribúdajú a release sa nedá zmeniť potom jeho vytvorení. Každá zmenu musí vytvoriť nový release.
 
-Builds are initiated by the app's developers whenever new code is deployed. Runtime execution, by contrast, can happen automatically in cases such as a server reboot, or a crashed process being restarted by the process manager. Therefore, the run stage should be kept to as few moving parts as possible, since problems that prevent an app from running can cause it to break in the middle of the night when no developers are on hand. The build stage can be more complex, since errors are always in the foreground for a developer who is driving the deploy.
+Buildy inicializujú developeri aplikácie kedykoľvek sa nasadzuje nový kód. Vykonávanie behu sa na rozdiel od buildov vykonáva automaticky v prípade reštartu servera, alebo pri reštarte padnutého procesu správcom procesov. Preto by fáza spustenia mala mať čo najmenej pohyblivých častí, keďže problémy, ktoré so spustením aplikácie môžu nastať v strede noci, keď developeri nie sú k dispozícii. Fáza build môže byť komplexnejšia, keďže chyby sú vždy viditeľné developerom, ktorí spustili nasadenie.
 

content/sk/concurrency.md

@@ -1,14 +1,14 @@
 ## VIII. Concurrency
-### Scale out via the process model
+### Škálovanie pomocou modelu procesov
 
-Any computer program, once run, is represented by one or more processes. Web apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume. Java processes take the opposite approach, with the JVM providing one massive uberprocess that reserves a large block of system resources (CPU and memory) on startup, with concurrency managed internally via threads. In both cases, the running process(es) are only minimally visible to the developers of the app.
+Každý počítačový program je po spustení reprezentovaný jedným alebo viac procesmi. Webové aplikácie sa objavujú v rôznych formách vykonávania procesov. Napríklad, PHP procesy bežia ako podprocesy Apachu, spustené na požiadanie podľa objemu požiadaviek. Java procesy prevzali opačný prístup, kde JVM poskytuje jeden masívny nadproces, ktorý si vyhradí veľké množstvo systémových prostriedkov (CPU a pamäte) pri spustení a súbežnosť spravuje interne cez vlákna. V obidvoch prípadoch sú bežiace procesy len minimálne viditeľné pre developera aplikácie.
 
-![Scale is expressed as running processes, workload diversity is expressed as process types.](/images/process-types.png)
+![Škálovanie je vyjadrené bežiacimi procesmi, rôznorodosť funkcionality je vyjadrená typmi procesov.](/images/process-types.png)
 
-**In the twelve-factor app, processes are a first class citizen.** Processes in the twelve-factor app take strong cues from [the unix process model for running service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to a *process type*. For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process.
+**V dvanásť faktorovej aplikácii sú procesy prvotriednymi obyvateľmi.** Procesy v dvanásť faktorovej aplikácii preberajú správanie z [modelu unix procesov pre démony služieb](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Použitím tohoto modelu, developer môže navrhnúť svoju aplikáciu tak, aby rôznu prácu vykonávali rôzne *typy procesov*. Napríklad, HTTP požiadavky môže spravovať webový proces, a dlho bežiace úlohy na pozadí môže spravovať worker proces.
 
-This does not exclude individual processes from handling their own internal multiplexing, via threads inside the runtime VM, or the async/evented model found in tools such as [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http:https://twistedmatrix.com/trac/), or [Node.js](http:https://nodejs.org/). But an individual VM can only grow so large (vertical scale), so the application must also be able to span multiple processes running on multiple physical machines.
+Toto nevylučuje, že si individuálne procesy nemôžu spravovať svoj interný multiplexing cez vlákna vnútri VM alebo interpretra, alebo async/event model v nástrojoch ako [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http:https://twistedmatrix.com/trac/), alebo [Node.js](http:https://nodejs.org/). Keďže individuálne VM môže rásť len obmedzene (vertikálne škálovanie), aplikáciu musí byť tiež schopná sa rozšíriť na viacero procesov bežiacich na viacerých fyzických strojoch.
 
-The process model truly shines when it comes time to scale out. The [share-nothing, horizontally partitionable nature of twelve-factor app processes](./processes) means that adding more concurrency is a simple and reliable operation. The array of process types and number of processes of each type is known as the *process formation*.
+Procesový model vyniká, keď príde čas rozširovania. [Nezdieľaná, horizontálne particionovateľná podstata procesov dvanásť faktorovej aplikácie](./processes) znamená, že pridanie väčšej súbežnosti je jednoduchá a spoľahlivá operácia. Súhrn typov procesov a počtu procesov každého typu sa nazýva *process formation*.
 
-Twelve-factor app processes [should never daemonize](http:https://dustin.github.com/2010/02/28/running-processes.html) or write PID files. Instead, rely on the operating system's process manager (such as [systemd](https://www.freedesktop.org/wiki/Software/systemd/), a distributed process manager on a cloud platform, or a tool like [Foreman](http:https://blog.daviddollar.org/2011/05/06/introducing-foreman.html) in development) to manage [output streams](./logs), respond to crashed processes, and handle user-initiated restarts and shutdowns.
+Procesty dvanásť faktorovej aplikácie [by sa nikdy nemali démonizovať](http:https://dustin.github.com/2010/02/28/running-processes.html) alebo zapisovať PID súbory. Namiesto toho by sa mali spoliehať na manažéra procesov operačného systému (ako napr. [systemd](https://www.freedesktop.org/wiki/Software/systemd/), distribuovaného manažéra procesov na cloudovej platforme, alebo nástroji ako [Foreman](http:https://blog.daviddollar.org/2011/05/06/introducing-foreman.html) počas vývoja) na spravovanie [výstupných streamov](./logs), reakcie na spadnuté procesy, a spravovanie userom iniciovaných reštartov a zastavení.