What is Reddit's opinion of Concourse?

From 3.5 billion Reddit comments

THIS !

I think whey readid there website since I tried it, back then they were pushing you into there free quota thing without telling you. I thought this was the OSS version, but the real OSS version is so stript down its lost nearly all it's advantages.

I liked it till it I hated it.

Currently I am looking as well. Jenkins is always an option but meh, and there is a system https://concourse-ci.org/ haven't tried it but it has some cool concepts.

Concourse (https://concourse-ci.org) is my current favorite. There is a learning curve but it's a nice modern approach to what a CI tool should be.

The downside is there are really no hosted offerings for it, but if you want to go self hosted it's great.

You can do this with concourse!

You setup a repo with a pipeline that uses the "set-pipeline" operation in your tasks, and then you can have it create pipelines for you. Then you only need to bootstrap that repo once with fly and you're good to go.

Example from the docs: https://concourse-ci.org/set-pipelines-example.html

I've recently joined an ops team for a startup, with an aim to take on devops responsibilities over time.

over the last week I've been introduced to:

-kubernetes-ibm Cloud-in-house applications-Concourse CI

I know the basics, where services live, how we manage service config and env config templates using git, and how our deployments get triggered using concourse and am starting to look at helm charts.

I've been introduced to how we manage secrets, some of our logging , and internal documentation on where to learn more.

It's unreasonable to expect someone to have these skills in any significant depth when they specifically aren't referenced in your experience in some form during the hiring process.

If your immediate manager is out/in hospital, i'd be surprised if another manager isn't taking on some of his responsibilities. Ask about that. Otherwise, go to whoever is next in the chain. If you are in a team, talk to them for advice. Perhaps they can budget time for this if it's communicated.

This isn't anything to be embarrassed about, just focus on good communication.

"I want to be successful.

A lot of the tooling in this role is new to me, and I'd like help getting the lay of the land and planning for my success, can you point me in the direction of someone that can help with that while <x> is out of office?"

If you are looking for a containerised build environment, which I was when I looked into DroneCI, there is Concourse-CI:

https://concourse-ci.org/

I both really like it and hate it at the same time. It has some really great ideas, but the naming scheme isn't one of them.

I'm not sure if it is a "good" alternative, but it is an alternative. It is different enough from other systems that it could be worth checking out.

I had tried it a while back. I didn't see any real advantages over Jenkins and the plugin ecosystem was really small. Also I found the pipeline -> stage-> job-> task structure a bit of an overkill. But this was about 5 years ago so maybe things have changed.

You should also look at concourse if you haven't already.

https://concourse-ci.org/

You could do this with concourse ci. https://concourse-ci.org/

Setup the docker image resource to listen for image changes https://github.com/concourse/docker-image-resource

Then you could call the nomad cli in a task or create / modify a nomad resource to publish the changes. Here is an example https://github.com/zarplata/nomad-resource (hasn't been updated in a while so may be stale)

No worries for the delay, we all have important stuff in our lives. While you where away I've kind of been implementing exactly what you are describing.

• My users now have local Linux accounts, they are NOT root via sudo or anything. The accounts are really locked down.
• They can use docker rootless (up to them really but i preinstalled it) and I activated systemd lingering so their enabled services autostart with the system (at multi-user.target).
• They SSH like you would think they do ssh username@hostdomain -i key.
  • I require public key auth for security reasons.
• I've implemented a CI/CD system (concourse ci) so that each user can automate their development pipelines.
• We run a PostgreSQL DB that everybody have access to, we discourage/disallow users to run their own large database servers for performance and management reasons. (backup and monitoring)
  • If a user needs a SQLite that's fine, or if a MySQL need to spin up for a couple of minutes each day, that's fine.

That's the setup right now, my plan is to implement some active security defenses like snort for scanning traffic. Another idea is a fileserver/CDN constantly scanned using CLAM, so that users applications can upload and download (pdf, json etc.) to that server. I've studied some computer security at university so I think I can manage those implementations. What I have problem with is implementing a mail-server with a HTTP API, (something like MailChimp), where users applications can send emails programmatically. We are really tired of working with MailChimp's payment model.

What are your opinions on this?
Thanks. :)

This is often-posted. https://roadmap.sh/devops

For CI/CD tools they recommend (in no particular order)

• Gitlab
• Jenkins
• Github Actions
• Circle CI

And offer as alternatives:

• Travis CI
• Bamboo
• Azure Devops (ADO)
• TeamCity

I would personally add Concourse to that second list. I think it's the most promising new CI/CD tool, but is not widely adopted by any measure.

It should be doable Docker compose is compatible with podman now just recheck the changelog.

https://concourse-ci.org/quick-start.html

https://github.com/concourse/concourse-docker

As for rootless that also should be possible you can use a reverse proxy as root.

If the work can be containerized then Concourse might be right for the job.

https://concourse-ci.org/

Here's an example of the web UI, in the form of Concourse's own CI pipelines https://ci.concourse-ci.org/

Pipelines themselves are pretty simple YAML. Build a docker image that does the job you want, hand it a little configuration in the task, and stand up two EC2 instances -- one runs the web process and one runs the worker process. Put them both in ASGs and scale them independently if you like.

So my 2 cents here is that CI/CD is the next step. There isn't much an interim between. CI/CD is usually what merges whatever code you want to push with podman commands to build the resulting container. A lot of the clients I deal with are using Jenkins and on the open source side Concourse. https://concourse-ci.org/

👋x-ops is a VERY broad topic - it has just as much breadth as general development, really. If you're interested in a TOOL that's floss and has a solid learning path, I've been digging into Concourse-ci lately (links below).

It's very capable, it's fully open-source, and has good learning material.

I've used 100 tools, but this one feels right, so far. I liked Jenkins, but didn't like its weight. I liked Drone, but didn't like its bill. I liked Gitlab CI, but I didn't like the runner setup. Concourse feels good, though.

Main page https://concourse-ci.org/ Very well-thought-out tutorial supplement (almost comparable to Angular's tour of heroes) https://concoursetutorial.com/

Requirements:

• Fully containerized
• Support execution of sequential and parallel commands
• Configured as code
• Exact logging
• Testable at both unit and functional levels
• Support templating
• Automatic and secure credential handling
• step
• stage
• pipeline

Soooo... they re-built Concourse-CI? https://concourse-ci.org/

:-/

maybe concourse? they call themselves "continuous thing-doer" which seems to fit :)

it has a pretty nice web ui for tracking the status of your jobs and the pipelines are just yaml that chains together code/scripts running in containers

there are also plenty of integrations available for it...

I had a CI system (Less CI, more like distributed cron) that I was working on for a while where I wanted to take the ideas from gaia and the ideas from concourse and combine them,

Interested to hear how what you're working on changes the game, since the market has been pretty interested in killing Jenkins for a while now.

<strong>passed</strong>: [string]

Optional. When specified, only the versions of the resource that made it through the given list of jobs will be considered when triggering and fetching.

package_a won't pass through BUILD_PACKAGE_B job, and package_B won't pass through BUILD_PACKAGE_A job either.

Perhaps it's worth mentioning that this kind of construction might be useful if you need to run an integration test that requires multiple resources.