Add custom docker image to site deployment

I’ve got a helm-based erpnext deployment and I use the related ‘create new site job’ template to deploy sites. Now, I’m trying to deploy a site along with a custom app.

I’ve created a custom erpnext-worker image using this: GitHub - castlecraft/custom_frappe_docker

From here, I’m unable to connect the dots. I know I need to get the image into a repo (it’ll be going into an AWS ECR repo). What needs to be done to deploy the custom worker image during
site creation? I found a thread (How to make a new app and install it on existing site · Issue #50 · frappe/helm · GitHub) that gets close to what I need but I’m not clear on the next step.

Thanks in advance.

Edit: It appears that pointing the ‘create new site’ job to my custom erpnext-worker image (which lives in an ECR repo) is all that’s needed. I’d test it but am back to chasing a db demon that I thought I’d conquered (mariadb/rds - db gets created but erpnext gets access denied when connecting to it - yes, I’m using rds_db).

If someone can validate that I’m on the right path with the custom image piece, it would be appreciated.

  • Once you’ve replaced your image in values.yaml for nginxImage and pythonImage the deployments will take the new image repo.
  • If you need credentials to pull images set it in values.yaml: imagePullSecrets: []
  • Using the python container execute bench --site <site> install-app app_name from /home/frappe/frappe-bench/sites That is now available instead of using console as mentioned in issue#50.
  • Even in job yaml you can add imagePullSecrets

Make sure you’ve set these things in appropriate config json files Using Frappe with Amazon RDS (or any other DBaaS) · frappe/frappe Wiki · GitHub

    "db_host": "",
    "rds_db": 1,

Yes you’re on right path.

Is the nginx image necessary? I’m using the erpnext helm chart and an aws load-balancer on the front-end. I don’t have any ‘nginx’ containers running so don’t think I need it but it’s always best to check.

frappe-nginx and erpnext-nginx are part of application, they are not your loadbalancer.

they are used to serve the static assets and reverse proxy gunicorn and socketio. If the image is removed then you need to replace those function with AWS LB. That means AWS LB should :

  1. serve static assets
  2. allow private/public files read write
  3. reverse proxy gunicorn
  4. reverse proxy socketio
  5. serve the bench error_pages.

I’d recommend not to touch any *-nginx image and treat them as part of application. Loadbalance in an additional layer above this application.

I created a fresh helm deployment using the erpnext helm chart . I created custom nginx and worker images, I mounted the worker image to make sure that my app was in there. It is. I edited the create-new-site job template, spec.template.spec.containers->create-site-> image to point to my private repository. I then applied the create-new-site job template.

The job ran successfully, site was created but no sign of my app. I tried manually installing through bench but it doesn’t know anything about the custom app.

Just to make sure I’m not overlooking the obvious, does the deployment need to be created using the custom images or is it okay to use them just for new site deployment? I should mention also that I would try creating with ‘bench new-site’ but there doesn’t seem to be an option to specify the image.

I created a new deployment using pythonImage and nginxImage parameters. The deployment went fine and the app is installed. Funny enough, the app does some theme hackery which doesn’t seem to be sticking in the kubernetes environment. Off to work on that now…

sites/apps.txt must have the app’s module name

  • there is a shared empty-dir volume in the 2 container pod
  • during container is started, nginx container copies all the assets from self to shared volume for python container to access them.

I think my remaining issue is down to customizations that normally occur as part of a bench build. You can’t do a build in the docker environment…no yarn…I’m sure this is intentional. I’m not sure how to achieve the same effect, though.

can you share a repo where I can reproduce the issue?

1 Like

The apps’ asset folder isn’t being created. Is there something else that needs to be run in the Dockerfile other than install-app?

The docker images are being built with this:

App repo:

Thanks for looking!

fix your nginx dockerfile

refer erpnext_feature_board/Dockerfile at main · revant/erpnext_feature_board · GitHub

ARG on line 3 ensures that correct image is pulled during build of nginx image.
If there is no ARG then frappe/erpnext-nginx:latest or frappe/frappe-nginx:latest will be pulled on line 19 of your nginx Dockerfile

1 Like

Well, that fixed the missing assets issue. Thanks again. Now I’m able to deploy a site in kubernetes and most everything is working fine. My app updates splash_image via I’ve confirmed that the assets are present in the image. Something in most be overwriting the modification. Maybe this is by design (that’s a separate discussion :slight_smile: ).

Currently digging to see how splash_image is called.

Once a new site has been created using custom erpnext and worker images, how does this impact helm upgrades? If upgrading from chart 3.2.35 to 3.2.40…but the custom images were built against v13.15.1 code (from 3.2.35)…is there a process to be followed to avoid conflict?

I think I found the answer. As part of the helm upgrade, the nginxImage and pythonImage files can be passed explicitly. So, it seems that as long as you reference updated packages, all is well.

1 Like