I have excercise where i have to deploy app war files onto multiple tomcat instances available on the same server. I am using Salt has my configuration mangement tool here, i have also gone through some examples of salt orchestrate runner but nothing seems to help. I am also confused arranging the pillar variables for multiple instances in the pillar file.
I am able to deploy app on only instance without any trouble.
Pillar file :
appname:
name : location to instance1 webapps folder
typer : war
State File:
archive.download:
download the war directly to instance1 webapp folder
cmd.run
restart instance1
Need help to include the second instance details and achieving the state deployment in optimized way possible. Thanks.
You might be able to use on the pillar side an array and then a jinja loop for the installation in the state file.
pillar:
applist:
- location : salt://path_to_archive_wi1
destination: /webapps_i1
name: test1
typer : war
- location : salt://path_to_archive_wi2
destination: /webapps_i2
name: test2
typer : war
- location : salt://path_to_archive_wi3
destination: /webapps_i3
name: test3
typer : war
state file:
{%- for app in salt['pillar.get']("applist",[]) %}
copy {{ app[name] }} :
file.managed:
- name: {{ app['destination'] }}
- source: {{ app['location'] }}
{%- endfor %}
Something like this should do it.
In the loop if you are only installing one app in one instance, you can also restart the instance.
Related
As I understand there is \Spryker\Shared\Config\Config::get method to access configuration stored in config/Shared dir. Does Spryker have anything similar to get values from deploy.*.yml files?
If you declare variables in deploy.*.yml
You can use them to set ENV in docker sdk
Example for passing env from deploy file to yves
Open file deploy.yml and add configuration
regions:
EU:
config:
something:
my_key: value
Then create twig for env in docker configuration.
docker/generator/src/templates/env/something/something.env.twig
Content of file
SOMETHING_MY_KEY={{ serviceData['my_key'] }}
Open yves twig for environment variables
docker/generator/src/templates/env/application/yves.env.twig
And add include for template
{% include "env/something/something.env.twig" with {
serviceData: project['regions']['EU']['config']['something'],
serviceName: 'something'
} %}
Make sure to pass correct name to access twing template and serviceData later.
After that you can add env variable to config file (config/Shared/config_*.php)
$config['<Const for my module>'] = getenv('SOMETHING_MY_KEY');
I am trying to configure tomee on our dev server. Here is the sample init file.
{% set user = pillar.x3ds.user %}
{% set tomee = pillar.tomee %}
{% set path = tomee.target_path %}
{% set service = tomee.service %}
target_path and service are saved in pillar files as seen below.
tomee:
service: app-server
target_path: /u01/tomee
version: 1_7_4
startup: startup
ports:
shutdown: 8005
http: 8080
ajp: 8009
jmx: 9099
I am able to retreive target_path but getting error as below for service.
Data failed to compile:
Rendering SLS 'base:tomee' failed: Jinja variable 'dict object' has no attribute 'app-server'
I am very new to saltstack and searched on google for quite sometime now. I am sure I am missing very basic thing but not able to get eactly. Your help would be appreciated.
I also tried set service diredctly in my init file but still see same error there also.
Root cause for error in my case was somewhere below in my init file. I was using service attribute to read a complex dict object I guess.
{- repl: Connector port="{{ site_index[service].http }}" protocol="HTTP/1.1"\1}
I am using the following way to provide bundled software project to salt minions:
proj-archive:
cmd:
- run
- name: "/bin/tar -zxf /home/myhome/Proj.tgz -C {{ proj_dir }}"
- require:
- file: /home/myhome/Proj.tgz
- {{ proj_dir }}
file:
- managed
- user: someone
- group: someone
- mode: '0600'
- makedirs: True
- name: /home/myhome/Proj.tgz
- source: salt://Proj.tgz
As far as I can tell, it does the job, but these rules are always active, even when archive have not changed. This brings unnecessary delays in deployment. In a similar situation, for example, service restart with watch clause on a file, it is possible to restart when file changed. How to tell salt to copy file over network only when it changed? Is there any automatic way to do it?
The Proj.tgz in salt directory is a symlink to file location, if it matters.
The archive.extracted is not that useful, because it does not trigger when changes are inside files, no files added or removed in the archive.
Some relevant info https://github.com/saltstack/salt/issues/40484 , but I am unsure of resolution / workaround.
You can replace both states with salt.states.archive. It might look like this:
proj-archive:
archive.extracted:
- name: {{ proj_dir }}
- source: salt://Proj.tgz
- user: someone
- group: someone
- source_hash_update: True
The key feature here is source_hash_update. From the docs:
Set this to True if archive should be extracted if source_hash has changed. This would extract regardless of the if_missing parameter.
I'm not sure whether or not the archive gets transferred on each state.apply. But I guess it will not.
I wish to store my slack api key so that it will be accessible from both Reactor states as well as states executed by minions (such as when running a highstate):
slack_api_key: xxx
If I add the data to a pillar, it can only be accessible from minions executing states:
{{ salt['pillar.get']('slack_api_key') }}
If I add the data to the master config, it can only be accessible from the Reactor:
{{ opts['slack_api_key'] }}
How can I store this data and be able to access it from both the Reactor and from states included in my highstate?
One solution is to set the following in the master configuration:
# The pillar_opts option adds the master configuration file data to a dict in
# the pillar called "master". This is used to set simple configurations in the
# master config file that can then be used on minions.
pillar_opts: True
# Slack API key
slack_api_key: 'xxx'
Then any data in the master configuration can be accessed like this...
From minions:
{{ salt['pillar.get']('master:slack_api_key') }}
- or -
{{ pillar['master']['slack_api_key'] }}
From Reactor:
{{ opts['slack_api_key'] }}
However, this is not a great answer, as any data in the master configuration is now exposed to minions.
You might try using sdb for this.
https://docs.saltstack.com/en/latest/topics/sdb/
We use salt to bootstrap our web server. We host multiple different domains. I create a file in /etc/apache2/sites-available for each of our domains. Then I symlink it to sites-enabled.
The problem is that if I move the domain to different server, the link from sites-enabled is not removed. If I change the domain name and keep the data in place - then I have old.domain.com and new.domain.com vhost files. I expect to end up with only new.domain.com in sites-enabled, but both files are there and the working domain depends on alphabet (I guess) - which of the vhosts is loaded first.
I have the domains stored in pillars and generate the vhosts like:
{%- for site in pillar.sites %}
/etc/apache2/sites-available/{{ site.name }}:
file:
- managed
- source: salt://apache/conf/sites/site
- template: jinja
- require:
- file: /etc/apache2/sites-available/default
- cmd: apache_rewrite_enable
- defaults:
site_name: "{{ site.name }}"
/etc/apache2/sites-enabled/{{ site.name }}:
file.symlink:
- target: /etc/apache2/sites-available/{{ site.name }}
- require:
- file: /etc/apache2/sites-available/{{ site.name }}
{% endfor %}
I need to make sure that only the vhosts listed in pillars stay after highstate. I thought about emptying the folder first, but that feels dangerous as the highstate may fail mid-air and I would be left withou any vhosts - crippling all the other domains - just because I tried to add one.
Is there a way to enforce something like: "remove everything that was not present in this highstate run"?
Yes, the problem is that Salt doesn't do anything you don't specify. It would be too hard (and quite dangerous) to try to automatically manage a whole server by default. So file.managed and file.symlink just make sure that their target files and symlinks are present and in the correct state -- they can't afford to worry about other files.
You have a couple of options. The first is to clean the directory at the beginning of each highstate. Like you mentioned, this is not ideal, because it's a bit dangerous (and if a highstate fails, none of your sites will work).
The better option would be to put all of your sites in each minion's pillar: some would go under the 'sites' key in pillar, and the rest might go under the 'disabled' key in pillar. Then you could use the file.absent state to make sure each of the 'disabled' site-files is absent. (as well as the symlink for those files)
Then when you move a domain from host to host, rather than just removing that domain from the pillar of the previous minion, you would actually move it from the 'sites' key to the 'disabled' key. Then you'd be guaranteed that that site would be gone.
Hope that helps!