FAQ
Hi all,

I have been using salt to deploy a couple of services over a couple of
dozens of machines using different versions of those services to some
success but there are some issues with the workflow I am using.

Every service has two versions: "dev" and "prod", that are based on the git
branches "develop" and "master" of every project.

Imagine I have have:

- Service 1: python program 1 - versions dev and prod
- Service 2: python program 2 - versions dev and prod (different repo than
service 1)
- Service 3: java program - versions dev and prod

What I have been doing to maintain both dev and prod environments is having
3 salt environments:

1. base: with common states like the python and java installation and more
common stuff like that.
2. dev: with the states to start the different services based on the pillar
dev settings: like branches and host names of the other services
3. prod: almost the same states as dev but a little bit behind in time

So every time i am developing i update the states on the dev saltenv and
when i need to make a new release I literally move those states to the prod
saltenv.

So i have some duplicated logic in the dev and prod directories, which i
don't like.

I used to have most of the service states in the base saltenv and include
then in the dev and prod saltenvs, but then other developers started to
work on this states and broke the prod environment (without noticing of
course, they were just developing), since the prod states were including
the base states.

So the best solution I found for that problem was to have some duplicated
state logic in different saltenvs and manually move/merge those salt
environments in every release.

Other solution that i have been thinking of is to do the same i do for the
services projects: have two git branches "develop" and "master" and have
two salt masters, one for the dev environment and a different one for the
prod environment. In that case I would remove the salt environments
probably just have one big base saltenv.

I am looking for better options since I am not completely happy with any of
those 2 solutions specially if i start having more environments: qa and
staging, the duplicated state logic could come of of control.

Thanks you for reading this long message and i apreciate any suggestion on
how people manage this time of problems.
Is there something inside salt that could help me with this issue?

Thank you,
Daniel

PD: Thanks for salt, I love it :D

--
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

  • Colton Myers at Aug 15, 2014 at 10:12 pm
    Hrm, off the top of my head I'm not sure of a way to do this cleanly and
    without duplicated logic across environments.

    I'll let my subconscious work on this one, see if I come up with anything.
      And this reply will serve as a bump, as well! Has anyone else solved a
    similar problem to this in their environments?

    --
    Colton Myers

    On Tue, Jul 29, 2014 at 1:14 PM, Daniel Rodriguez wrote:

    Hi all,

    I have been using salt to deploy a couple of services over a couple of
    dozens of machines using different versions of those services to some
    success but there are some issues with the workflow I am using.

    Every service has two versions: "dev" and "prod", that are based on the
    git branches "develop" and "master" of every project.

    Imagine I have have:

    - Service 1: python program 1 - versions dev and prod
    - Service 2: python program 2 - versions dev and prod (different repo than
    service 1)
    - Service 3: java program - versions dev and prod

    What I have been doing to maintain both dev and prod environments is
    having 3 salt environments:

    1. base: with common states like the python and java installation and more
    common stuff like that.
    2. dev: with the states to start the different services based on the
    pillar dev settings: like branches and host names of the other services
    3. prod: almost the same states as dev but a little bit behind in time

    So every time i am developing i update the states on the dev saltenv and
    when i need to make a new release I literally move those states to the prod
    saltenv.

    So i have some duplicated logic in the dev and prod directories, which i
    don't like.

    I used to have most of the service states in the base saltenv and include
    then in the dev and prod saltenvs, but then other developers started to
    work on this states and broke the prod environment (without noticing of
    course, they were just developing), since the prod states were including
    the base states.

    So the best solution I found for that problem was to have some duplicated
    state logic in different saltenvs and manually move/merge those salt
    environments in every release.

    Other solution that i have been thinking of is to do the same i do for the
    services projects: have two git branches "develop" and "master" and have
    two salt masters, one for the dev environment and a different one for the
    prod environment. In that case I would remove the salt environments
    probably just have one big base saltenv.

    I am looking for better options since I am not completely happy with any
    of those 2 solutions specially if i start having more environments: qa and
    staging, the duplicated state logic could come of of control.

    Thanks you for reading this long message and i apreciate any suggestion on
    how people manage this time of problems.
    Is there something inside salt that could help me with this issue?

    Thank you,
    Daniel

    PD: Thanks for salt, I love it :D

    --
    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.
  • Daniel Bryan at Aug 16, 2014 at 1:23 am
    At Learnosity, we solved this problem by creating a separate production
    salt-states repo and adding our existing states as a submodule.

    That means any production-specific states and the prod pillar are isolated,
    and we have control over pulling in the states from dev thanks to the git
    submodule being checkpointed at a single commit.

    It works very well: people can basically change the base states to work and
    dev and staging with impunity, and when we run `git pull` in the submodule
    we see exactly what has changed.

    --
    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 @
postedJul 29, '14 at 7:14p
activeAug 16, '14 at 1:23a
posts3
users3

People

Translate

site design / logo © 2022 Grokbase