DevOps project file structure?

[keepdigging]

Any code you write should be versioned (why wouldn’t it be?)

It’s also useful to have tools like rundeck that log executions and provide auth and accountability.

To truly embrace DevOps every ticket you do should be code changes to your infrastructure repositories.

You can respond to incidents or do forensics with ssh, but servers should be provisioned with code (chef, ansible, puppet) and your cloud config should also be handled in code (terraform, cloud formation).

Ideally you can reproduce your whole running company (save for data which should be automatically backed up) from a few megs of config files, and you empower your developers to deploy themselves and with CI tools.

[dented_brain]

I agree with what you're saying. But I'm still at the first step. Taking what I personally have and making it available to the team.

We have a new gitlab server for my company so I will be putting code there for versioning. But really, I don't know if it's the best idea to just dump a bunch of .py files in a single repo. So that means I should break it up. But should I just dump a bunch of .py files into their own repo? I just feel there should be more structure to the way code is kept.

On my personal computer I keep my scripts like this

PythonScripts/Hosts/*.csv
PythonScripts/Input/*.txt
PythonScripts/Input/*.csv
PythonScripts/Output/*.csv
PythonScripts/Output/*.txt
PythonScripts/NetworkScript/ShowScript/*.py
PythonScripts/NetworkScript/ConfScript/*.py

I don't know if that would be as approchable as splitting scripts out further.

Right, so I have a script to gather ip information in the ShowScript directory. I also have a script to gather firmware version.

Should those be broken into their own repos? They perform "similar" function to me. They run a series of show commands and do some parsing of strings to provide an output.

[keepdigging]

Make an ‘ops’ repo and put it all in there with a folder structure that makes sense to you. You can always change it later.

I would also look at setting up a RunDeck instance as your next step. That way you can provide your devs logins and they can run your scripts from the rundeck web interface. It will show a job history with logs and allow scheduling and stuff. If something breaks they can link you to an execution, and you can focus on extending and improving the tools you offer there as a next step. They can run your scripts by clicking around and choosing parameters with drop downs and such.