by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Jason Frey
@Fryguy
yeah, you know I was going to ask if we can change that, cause I was hitting the persistence issue too
I had an idea where we have a volume for these handful of files, and then symlink them on start or something
Nick Carboni
@carbonin
Well it will persist at runtime if you run the container multiple times
Jason Frey
@Fryguy
yeah
Nick Carboni
@carbonin
The problem is during build
Jason Frey
@Fryguy
yeah true
Nick Carboni
@carbonin
Or if you want to use the same volume across multiple containers I guess? But you would have the same issue if we put the volume somewhere else.
I think the issue here is that the things we want to persist at runtime are co-located with stuff people might want to change at build-time

I had an idea where we have a volume for these handful of files, and then symlink them on start or something

Yeah, something like that could work

Jason Frey
@Fryguy
ok, I might iterate on that in my free time
Nick Carboni
@carbonin
:thumbsup:
Jason Frey
@Fryguy
do you know of anything else besides GUID, v2_key, and database.yml? (I think cable.yml and a certs/server_key)
Nick Carboni
@carbonin
Actually I think certs would be a good candidate for something someone might want to add while building the image. I'm not sure what the workflow is for that in the monolithic image actually
Jason Frey
@Fryguy
it's generated on first boot
Nick Carboni
@carbonin
Maybe logs if we're writing those out and want to persist them.
Jason Frey
@Fryguy
At least it looks that way :)
yeah, I was considering logs, but I'd almost prefer disabling the log dir by default, and lean on docker logs
Nick Carboni
@carbonin
Yeah I'm sure it is. But then we could continue to overwrite on first boot. It's self-signed so it's not going to get any more secure if we don't change it
Jason Frey
@Fryguy
true
ok cool...I'll play around with this idea
FWIW, I built a CLI that launches the docker image with sensible defaults, and then it can also run as a Mac service (like systemd, it will restart on failure, etc)
I just do manageiq start and I have an MIQ...awesome for quick demos / double checks
Nick Carboni
@carbonin
Nice!
Joris Vleminckx
@jvleminc
In our case we can't appy custom branding; took me quite a while to understand that the VOLUME is the culprit (when running a custom docker build, the cp commands evemn give valid output but in the end no files are replaced). :-(
Jason Frey
@Fryguy
oh branding! that's another one
@jvleminc you're talking about the branding via "upload image" in the UI?
or are you modifying the source directly?
Martin Hradil
@himdel
there's also public/custom.css
Joris Vleminckx
@jvleminc
We do something like this:
COPY branding/* ${APP_ROOT}/
RUN cp -v ${APP_ROOT}/login-screen-logo.png $( find ${RUBY_GEMS_ROOT}/bundler/gems/ -name login-screen-logo.png ) && \
    cp -v ${APP_ROOT}/login-screen-logo.png $( find ${APP_ROOT}/public/assets/layout/ -name "login-screen-logo-*.png" ) && \
    cp -v ${APP_ROOT}/brand_atmosphera.svg  $(find ${APP_ROOT}/public/assets/layout/ -name brand-*.svg)
Jason Frey
@Fryguy
ah ok, yeah so you're patching the source effectively
one way around that is to actually keep the code committed in a repo
then build the images from that repo
Joris Vleminckx
@jvleminc
Sure, but it's easier to start from the base docker image :-)
I also found some procedure do "unvolume" the base image, but that's also not ideal.
Jason Frey
@Fryguy
of course :)
but if my idea of extracting the identity files into a separate volume work, that would probably solve your problem because the APP_ROOT volume would go away
Joris Vleminckx
@jvleminc
Yes, or move the VOLUME definitions further downwards, towards the real inmutable stuff should work.
Jason Frey
@Fryguy
I thought the APP_ROOT was the last line already
Joris Vleminckx
@jvleminc
Correct, I meant that the VOLUME could be applied to that part of the path where it's really needed.
Jason Frey
@Fryguy
oh yes exactly
Joris Vleminckx
@jvleminc
Would this be something doable in a new ivanchuk release?
Nick Carboni
@carbonin
Unfortunately at least one of the files we need to persist (GUID) is actually directly in APP_ROOT
When deploying in kube this is all driven by env vars so we don't need a volume, but that's kind of cumbersome for running a single image.
We could do something like store all the config in /etc/manageiq/config or something then set the envs from there in the entrypoint.
Might be harder for stuff that isn't config and isn't driven by env though
Jason Frey
@Fryguy
yeah literally exactly what I was thinking ... /etc/manageiq/config and then mount that
it might need code changes to support that...haven't quite wrapped my head around "new" files getting into there
Joris Vleminckx
@jvleminc
Ok, for now I have started to use this script: https://github.com/gdraheim/docker-copyedit
Works fine.
LionKingDev
@Peter0529
Hi everyone
How could i add field to user table in manageiq?
Is there activation field for user in db?
And how could i add dummy new user?
hkj96
@HKJ96
Hi, @Peter0529
There is no field for activation. To create a dummy user is quite easy... you just need to fill in 4 fields