I currently have a Docker Compose file I’ve been using for development, and I’m looking into Nomad to horizontally scale some services.
If I switch to Nomad, would I need Docker Compose anymore? Or do most people just run sudo nomad agent -dev and develop with that locally? Or something else?
Bump.
tl;dr It seems like Nomad would replace Docker Compose for me. How do people usually develop with Nomad? Do they also have Docker Compose files and update both? Just use Nomad for a dev environment? Something else?
I have the same question. Deploying jobs to a staging and production cluster seems trivial…however, I am wondering what workflows are using to enable devs to work locally. We also use docker-compose right now for local development.
I realize I’m really late to this party but I wanted to share our experiences since we grapped with the same question(s) @adawalli and @cashihorp. While I could not possibly sum up all the details, it’s gonna be a little long winded, so I apologize in advance but I think some context is necessary 
To start with we had to decide what level of “hashicorp” product integration and knowledge we wanted service teams to have - and the answer was minimal, not because the product isn’t worth the investment of time but because, at the end of the day, those engineers are primarily focused on writing services. So the first thing(s) we did was focus on CONTAINER first (nothing with orchestrators). This meant ensuring everything was configuration driven in the container, and containers themselves never used vault/consul but if they did, they took in values as config (I’ll get to this again later). For service discovery we deployed client side load balancers so that containers didn’t have to do service discovery and instead just always spoke to localhost (connect is a different story but way out of scope here)
Then we had our engineers do everything in docker-compose. All unit testing, integration within the service (to mocks, etc) all using docker-compose. This allowed our engineers to be sheltered from secrets management, vault policies, tokens, and so on.
Another decision we made was to make our platform (Hashistack) something that could be stood up on a single vagrant node. This was so that when teams were ready (service) and wanted to test writing their jobs, they could do so without ever entering the pipeline. Once that was all done - off to the CI/CD races they go
So TLDR Version:
Hope this gets some insight - please feel free to ask specifics and I’ll answer as soon/best I can
Ian
One addition I would like to pitch in, just as an idea, is the following:
For the step “single node vagrant” it would be good to configure the single node as a “server + client” rather than nomad agent -dev as dev mode does some things different.
The drift between prod and “single node vagrant” could thus be made minimal.
A few years before I joined the Nomad engineering team I was a Nomad operator and PE for a startup where I ran into this same question. For us the big thing that was missing to make a development workflow work with Nomad locally was not having the docker-compose build and build configuration.
I ended up building a single-node Vagrant host just as @shantanugadgil and @idrennanvmware have suggested, but it was mostly used for integration testing and not day-to-day development.
In my opinion shipyard would also be a good starting point.
Shipyard is a tool for building modern cloud native development environments. Using the Shipyard configuration language you can create Docker containers, Nomad/Kubernetes clusters and more. Shipyard understands terraform
good suggestion on shipyard!
One thing, in general, that I want to call out (and we encountered) was that for rudimentary cases these individual tools all worked well BUT we have a lot of vault policies, secrets and kv management/integration, and so on that were impossible to test effectively in job files without us having the proper system (which was why we went for a 1 node stack deployment for our platform implementation). May be far more complicated than most need but wanted to share that extra consideration