#random (2021-02)

wow, that’s bring memory, I built something like that using https://getbootstrap.com/docs/5.0/examples/starter-template/ only static content can be added, I added ip/url: port and create my ownlist - dockerize it with nginx

Yeah, we have 5/6 envs with specifics urls, I remember of a already-built project that takes data from config map. it would fit more our need. will continue to dig and report here if i found it

Found this https://github.com/bastienwirtz/homer but the ui looks a bit too overloaded

nice tool, thanks for sharing, I’m thinking of get all service from nginx/apache config and add them there automatically since I’m working with lot of reverse proxy services and projects

How about this one: https://github.com/stakater/Forecastle ?

Thanks, that’s exactly it!!

Good summary here https://www.theregister.com/2021/02/02/slack_outage_aws_autoscaling/

https://www.keycloak.org/

I tested it only for fun, but see good amount of hype configure it using Terraform,

https://registry.terraform.io/providers/mrparkers/keycloak/latest/docs

big beast,

needs a lot of effort to maintain and keep HA. If used in prod it becomes the crucial part of your entire org. If it sneezes sh*t hits the fan!

I am not saying its bad but it need more effort then your usual self-hosted soft

Have used it previously - single node within a Java stack for a small number of users (~50). It works well, but it’s a complicated beast.

My team has been using it for just over a year, supporting about 1000 employees (it is the auth broker for GitLab so we can centralize the SAML connection to corporate SSO).

It is powerful, configurable, sometimes very complicated, but overall a positive experience.

Since the user/group management is done elsewhere, we run our Keycloak stateless. Full Configuration as Code (CaC), no database (it has an internal H2 in-memory database). Since it is running in kubernetes, it auto-heals easily with minimal downtime. We haven’t spent the time to figure out how to do HA yet, but we haven’t seen the need to either (GitLab isn’t mission critical. If it goes down nobody is going to die, unlike some other stuff we do…).

You might want to take this warning into consideration

https://www.gluu.org/blog/keycloak-is-the-next-centos/

I’ll cross that bridge when I come to it. If it happens I think it is likely that the community will fork keycloak and provide a mostly-drop-in replacement.

That article is a shill for Gluu, since Janssen is maintained by Gluu people, just like Keycloak is (mostly) maintained by Red Hat people.

Yeah, fair enough

Thanks all! I appreciate it and I’m sure I’ll have more questions once I get into using it.

I build and push in same stage usually but for the times I don’t I save and load image

Yeah, I also build and push at the same time.

Another thing you could do is push the image to the Gitlab container registry in the build stage and let the publish stage be:

• pull from gitlab

• retag

• Push to ECR That way you could push the same image to different repositories/environments without rebuilding. And decouple the build from publish.

IMO there’s no reason to have a discrete build stage. If you make each stage independent, then “test” will first build the image if it needs to. “Publish” will also build if it needs to (it might not, depending on how caching/execution is set up).

But in my example, test stage uses ‘node’ base image and performs linting and unit testing without involving docker. Is this something wrong or? As I understand docker image should have instructions on how to run the app, not how to run, test, etc.

But if I understand what you are saying is to have ‘test’ stage and then ‘publish’ stage that builds tags and publishes docker image.

truth