Understanding the nuances of salt git state for quickly rolling back a deployment.

[lu...@localprojects.net]

Hello,

I'm working on a salt based deployment system that will be based on develop/stage/master branches.  The idea is to have the various branches trickle their way up through servers until they make their way onto the master branch / production server.  

I need the option to quickly roll back a deployment on the production server in case the code fails.  In here lies my question.  Our deployments can be very large, so I'm trying to understand how salt manages the folder that contains the git repo. Does it wipe out the folder and send a new tarball each time?  Does it use git to somehow manage a remote repository?  etc

thanks

[Colton Myers]

Are you using the git state for the git repo you're managing?  When you talk about tarballs, are you using the git.archive module function?

More information on what you're trying to do and how you're trying to do it will help us to better answer your questions.

--

Colton Myers

--
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+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Lucas Vickers]

I think I've since figured out thanks to UtahDave.

My understanding now is that the standard - git entries in the .sls cause the minion to have git repositories on it's local machine.  Ie the master tells the minion to run things like "get clone, git update, etc"

An alternative to this is the gitfs in which the files will be checked out onto the master and served to the minions.  This does lead me towards a question of how salt handles this type of operation.  Does salt get checksums of files in managed directories and just update what has changed with new files?  Send some kind of file diff? etc  This is kinda the level of info I'm looking for.

When I was talking about tarballs I was thinking maybe when you put a -git in the sls the master checks out the files locally and pushes them down - but I don't think that is how it works.

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/4Tp0tIY2eOY/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Colton Myers]

The gitfs fileserver backend allows you to use a remote (or local) git repository as part or all of your environment.  Basically it will serve the same purpose /srv/salt serves by default.  Each branch is automatically used as an environment of the same name, except for master, which is used as the 'base' environment.

More info:  http://docs.saltstack.com/topics/tutorials/gitfs.html

--

Colton Myers

[Valentin Bud]

Hello,

The gitfs [1] docs could use some love :-). A short example on how to configure a gitfs remote over SSH would prove very useful to the community. 

Let's say for example I have a remote located at g...@git.domain.tld:salt-states.git (gitolite installation there).

How would I configure the master in this case?

Would the following be enough? First some information about my environment.

OS

--

$ uname -a

Linux godzilla 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.41-2~bpo60+1 x86_64 GNU/Linux

Salt Master

--

$ salt-master --version

salt-master 0.15.1

/etc/salt/master

--

 

$ grep gitfs_remotes /etc/salt/master

gitfs_remotes: git+ssh://g...@git.domain.tld:salt-states.git

The connection is done over SSH with keys. How would one specify which user and key to use for the connection?

For example I would like to have a user, salt-master, with a key saved in /etc/salt/pki/master/id_rsa. This user would have read access granted in gitolite to the repo salt-states. User in this case is a gitolite user *only*.

salt-master is running as root. Is the /root/.ssh/id_[rd]sa key used by salt-master when cloning the remote? In this case is simple, one would just generate root keys without passphrase and insert them in gitolite under salt-master user.

Another approach would be to run salt-master under another user, salt for example, and use that user's key. 

Thoughts?

Cheers and Goodwill,

Valentin Bud

http://databus.pro/ | vale...@databus.pro

[Colton Myers]

I was about to reply and tell you that gitfs doesn't support key authentication for private repos, but apparently someone has pulled it off: https://groups.google.com/forum/?fromgroups#!searchin/salt-users/gitfs/salt-users/AI-cOAtlYMg/VYzbsyNuSvMJ

However, it does require you putting the key in the salt user's ~/.ssh folder (usually /root/.ssh), you can't specify a specific key location. Though that's definitely something we want to add when we have time.

--

Colton Myers

[Valentin Bud]

Hello Community,

I have written a small description on how to configure a gitfs_remotes over SSH transport.

https://github.com/valentinbud/salt/commit/f9e74255d20255127cf780be1784a4d69477bdf7

Debian Squeeze specifics:

I had to install gitpython from pip because the python-git Debian package is at version 0.1.6-1

and Salt requires git-python > 0.3.0.

Thanks for Salt :-),

Cheers and Goodwill,

[Lucas Vickers]

Sorry for dropping out on this topic for a bit.

So let's say I make gitfs my file fileserver_backend on master when serving to minion-develop and minion-master.

When I hit 'salt minion-develop state.highstate', my master will check out (or update) the git branch somewhere on the master machine and host those files to the minion-develop.

Can I specify a branch for the repos?  What if I want minion-develop on the develop branch and minion-master on the master branch?

The gitfs documentation needs some love, it's true :)

[Thomas Kula]

On Fri, Jun 28, 2013 at 02:04:25PM -0400, Lucas Vickers wrote:
> Sorry for dropping out on this topic for a bit.
> So let's say I make gitfs my file fileserver_backend on master when
> serving to minion-develop and minion-master.
> When I hit 'salt minion-develop state.highstate', my master will check
> out (or update) the git branch somewhere on the master machine and host
> those files to the minion-develop.
> Can I specify a branch for the repos? What if I want minion-develop on
> the develop branch and minion-master on the master branch?
> The gitfs documentation needs some love, it's true :)

I've just started playing with this, and my current understanding is
this: with gitfs fileserver_backends, git branches and tags correspond
to salt environments, with a one-to-one correspondence --- *except* that
the salt 'base' environment becomes the gitfs/git repo 'master' branch.

So, create a git repo, and in the master branch have all the files for
minion-master and your top.sls:

'base':
'minion-master':
- stuff

'develop':
'minion-develop':
- stuff

And then in the git repo create a branch or a tag called 'develop' and
put the stuff for minion-develop in there.

At least, this seems to be the way it works for me.


--
Thomas L. Kula | ku...@tproa.net | http://kula.tproa.net/

[Lucas Vickers]

that makes a good deal of sense!

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/4Tp0tIY2eOY/unsubscribe.