FAQ
Hi,

I'm having some problem understanding environments etc.
In section 3.3.5 (practical-example
<http://docs.saltstack.com/en/latest/topics/tutorials/states_pt4.html#practical-example>)
there is an example covering these aspects.
In this example environments are set like so:


file_roots:
   base:
     - /srv/salt/prod
   qa:
     - /srv/salt/qa
     - /srv/salt/prod
   dev:
     - /srv/salt/dev
     - /srv/salt/qa
     - /srv/salt/prod

Just to be clear here, what are the environments here?
Are they base, qa and dev, or are they prod, qa, and dev?


top.sls in /srv/salt/prod/top.sls:
base:
   'web*prod*':
     - webserver.foobarcomqa:
   'web*qa*':
     - webserver.foobarcomdev:
   'web*dev*':
     - webserver.foobarcom

There is also /srv/pillar/top.sls:
base:
   'web*prod*':
     - webserver.prod
   'web*qa*':
     - webserver.qa
   'web*dev*':
     - webserver.dev

where webserver_role is set to: prod, qa and dev
respectively. Finally the magic happens in:
/srv/salt/prod/webserver/foobarcom.sls:
{% if pillar.get('webserver_role', '') %}
/var/www/foobarcom:
   file.recurse:
     - source: salt://webserver/src/foobarcom
     - env: {{ pillar['webserver_role'] }}
     - user: www
     - group: www
     - dir_mode: 755
     - file_mode: 644
{% endif %}
There are two things here I have some trouble with:
1. Environments, the "- env" line in the state, to me
it would seem more natural if pillar would give either
"base", "qa" or "dev" instead of "prod", "qa or "dev", or,
if there were a dedicated "prod"-environment defined?

2. To me it would also seem cleaner with a different
top.sls:
base:
   'web*':
     - webserver.foobarcom
i.e., only having to "define" the different systems at one place
(pillar) instead of two (both pillar and top.sls). Would this
work?

Kind regards,
/jon

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Warren Turkal at Nov 3, 2014 at 11:56 pm

    On Sunday, November 2, 2014 1:20:34 AM UTC-8, Jon wrote:
    Hi,

    I'm having some problem understanding environments etc.
    In section 3.3.5 (practical-example <http://docs.saltstack.com/en/latest/topics/tutorials/states_pt4.html#practical-example>) there is an example covering these aspects.
    In this example environments are set like so:


    file_roots:
    base:
    - /srv/salt/prod
    qa:
    - /srv/salt/qa
    - /srv/salt/prod
    dev:
    - /srv/salt/dev
    - /srv/salt/qa
    - /srv/salt/prod

    Just to be clear here, what are the environments here?
    Are they base, qa and dev, or are they prod, qa, and dev?
    The environments are base, qa, and dev. To be precise, this is configuring
    where files for the fileserver live. The "base" environment serves files
    located in "/srv/salt/prod" in this example.

    top.sls in /srv/salt/prod/top.sls:
    base:
    'web*prod*':
    - webserver.foobarcomqa:
    'web*qa*':
    - webserver.foobarcomdev:
    'web*dev*':
    - webserver.foobarcom
    This is the mapping of machines into envinronments. Keep in mind that
    machines can be in multiple environments. For example, if you had a machine
    named "web-prod-qa-dev", it would match all of the patterns and be in the
    base qa and dev envionrments and have the listed states from each
    environment applied. Environments are not necessarily mutually exclusive
    sets. They can be more like a venn diagram.

    There is also /srv/pillar/top.sls:
    base:
    'web*prod*':
    - webserver.prod
    'web*qa*':
    - webserver.qa
    'web*dev*':
    - webserver.dev
    This is kinda complicated. I don't think this file has anything to do with
    environments. I don't think that concept exists in pillars. The "base" here
    is basically a meaningless but unique name to group the other bits. The
    other bits are matchers and lists of pillar files to include for a
    particular machine. This file is interpreted by the master, not the minions.

    where webserver_role is set to: prod, qa and dev
    respectively. Finally the magic happens in:
    /srv/salt/prod/webserver/foobarcom.sls:
    {% if pillar.get('webserver_role', '') %}
    /var/www/foobarcom:
    file.recurse:
    - source: salt://webserver/src/foobarcom
    - env: {{ pillar['webserver_role'] }}
    - user: www
    - group: www
    - dir_mode: 755
    - file_mode: 644
    {% endif %}
    There are two things here I have some trouble with:
    1. Environments, the "- env" line in the state, to me
    it would seem more natural if pillar would give either
    "base", "qa" or "dev" instead of "prod", "qa or "dev", or,
    if there were a dedicated "prod"-environment defined?
    Why are you defining "env" expllicitly? You shouldn't have to worry about
    setting that. Env is usually determined implicitly from which environment a
    state is used from. In your example above, if you have
    /src/salt/prod/webserver/foobarcom.sls, that will be used in all the
    environments unless it is overridden in either qa or dev. There's no reason
    to set env.

    2. To me it would also seem cleaner with a different
    top.sls:
    base:
    'web*':
    - webserver.foobarcom
    i.e., only having to "define" the different systems at one place
    (pillar) instead of two (both pillar and top.sls). Would this
    work?
    The separation allows the master to interpret the pillars and the minions
    to interpret the file serving environments. This allows pillars to be used
    to deploy machine specific and security sensitive data since the master
    controls how pillars are applied.

    wt

    >

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jon Tegner at Nov 4, 2014 at 6:40 am
    Thanks for answering! Just want to add that the example is not mine - it is
    from the documentation, and my concern is that I find it a bit hard to
    follow. Best thing for me is probably to code it myself (and just possibly
    come up with an example easier to follow).

    Regards,
    /jon
    Den 4 nov 2014 00:56 skrev "Warren Turkal" <wt@signalfuse.com>:
    On Sunday, November 2, 2014 1:20:34 AM UTC-8, Jon wrote:

    Hi,

    I'm having some problem understanding environments etc.
    In section 3.3.5 (practical-example <http://docs.saltstack.com/en/latest/topics/tutorials/states_pt4.html#practical-example>) there is an example covering these aspects.
    In this example environments are set like so:


    file_roots:
    base:
    - /srv/salt/prod
    qa:
    - /srv/salt/qa
    - /srv/salt/prod
    dev:
    - /srv/salt/dev
    - /srv/salt/qa
    - /srv/salt/prod

    Just to be clear here, what are the environments here?
    Are they base, qa and dev, or are they prod, qa, and dev?
    The environments are base, qa, and dev. To be precise, this is configuring
    where files for the fileserver live. The "base" environment serves files
    located in "/srv/salt/prod" in this example.

    top.sls in /srv/salt/prod/top.sls:
    base:
    'web*prod*':
    - webserver.foobarcomqa:
    'web*qa*':
    - webserver.foobarcomdev:
    'web*dev*':
    - webserver.foobarcom
    This is the mapping of machines into envinronments. Keep in mind that
    machines can be in multiple environments. For example, if you had a machine
    named "web-prod-qa-dev", it would match all of the patterns and be in the
    base qa and dev envionrments and have the listed states from each
    environment applied. Environments are not necessarily mutually exclusive
    sets. They can be more like a venn diagram.

    There is also /srv/pillar/top.sls:
    base:
    'web*prod*':
    - webserver.prod
    'web*qa*':
    - webserver.qa
    'web*dev*':
    - webserver.dev
    This is kinda complicated. I don't think this file has anything to do with
    environments. I don't think that concept exists in pillars. The "base" here
    is basically a meaningless but unique name to group the other bits. The
    other bits are matchers and lists of pillar files to include for a
    particular machine. This file is interpreted by the master, not the minions.

    where webserver_role is set to: prod, qa and dev
    respectively. Finally the magic happens in:
    /srv/salt/prod/webserver/foobarcom.sls:
    {% if pillar.get('webserver_role', '') %}
    /var/www/foobarcom:
    file.recurse:
    - source: salt://webserver/src/foobarcom
    - env: {{ pillar['webserver_role'] }}
    - user: www
    - group: www
    - dir_mode: 755
    - file_mode: 644
    {% endif %}
    There are two things here I have some trouble with:
    1. Environments, the "- env" line in the state, to me
    it would seem more natural if pillar would give either
    "base", "qa" or "dev" instead of "prod", "qa or "dev", or,
    if there were a dedicated "prod"-environment defined?
    Why are you defining "env" expllicitly? You shouldn't have to worry about
    setting that. Env is usually determined implicitly from which environment a
    state is used from. In your example above, if you have
    /src/salt/prod/webserver/foobarcom.sls, that will be used in all the
    environments unless it is overridden in either qa or dev. There's no reason
    to set env.

    2. To me it would also seem cleaner with a different
    top.sls:
    base:
    'web*':
    - webserver.foobarcom
    i.e., only having to "define" the different systems at one place
    (pillar) instead of two (both pillar and top.sls). Would this
    work?
    The separation allows the master to interpret the pillars and the minions
    to interpret the file serving environments. This allows pillars to be used
    to deploy machine specific and security sensitive data since the master
    controls how pillars are applied.

    wt
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedNov 2, '14 at 9:20a
activeNov 4, '14 at 6:40a
posts3
users2

2 users in discussion

Jon Tegner: 2 posts Warren Turkal: 1 post

People

Translate

site design / logo © 2022 Grokbase