Custom Frappe Docker with HRMS App | Tables tabdepartment and tabtask is marked as crashed and should be repaired

Install / Update
, ,
4

You have to run this command first
bench get-app https://github.com/frappe/hrms

After this, then run
bench --site erp.sitename.com install-app hrms

5

When I run bench get-app it I just get “Error: Only Frappe framework bench commands are available in container setup.”
I am trying to run within the erpnext backend container. Was hoping to do it without making an custom app container but seems not possible. seeing as this is a standard frappe app I don’t know why this cant be directly available in frappe_docker.

6

The official frappe Docker only ship Frappe and ERPNext in its image.

If you need HRMS you need to build your own custom image using the steps in the official frappe docker documentation.

I have built a custom image with HRMS app. You can refer to this repo for reference

You can refer to the post for more information frappe docker with custom app error

1 Like
8

This procedure you presented is for loading the hrms module with the existing erpnext docker installation, or is this a whole new instance that will have hrms as well?

9

for existing instance you can follow these steps:

  • replace the image: to new one with new app(s) and redeploy.
  • run the command ls -1 ../apps > apps.txt with sites volume attached to worker image/container. This will re-create apps.txt file with all the apps now included with new image.
  • after that you proceed to use bench helper Frappe Commands like install-app, uninstall-app.

For re-creating assets refer frappe_docker/setup-options.md at main · frappe/frappe_docker · GitHub

or add populate-assets service like this that will run once after each re-deploy ERPNext on Docker Swarm · GitHub

1 Like
10

The above procedure is to create a new Docker image with HRMS Module.

1 Like
11

Is there a guru out there that would be kind enough to docker compose a package with ERPNext and HRMS? Seems like it would be useful rather than trying to package them all. I’ve attempted a few times and haven’t had much luck.

12

I already have a repo and a image pre built with HRMS
Please find the same here in our repo

update your frappe-docker/custom_app/ compose.override.yaml like below

services:
  configurator:
    image: ghcr.io/lmnaslimited/lensdocker/worker:${VERSION}

  backend:
    image: ghcr.io/lmnaslimited/lensdocker/worker:${VERSION}

  frontend:
    image: ghcr.io/lmnaslimited/lensdocker/nginx:${VERSION}

  queue-short:
    image: ghcr.io/lmnaslimited/lensdocker/worker:${VERSION}

  queue-default:
    image: ghcr.io/lmnaslimited/lensdocker/worker:${VERSION}

  queue-long:
    image: ghcr.io/lmnaslimited/lensdocker/worker:${VERSION}

  scheduler:
    image: ghcr.io/lmnaslimited/lensdocker/worker:${VERSION}

Create a new Variable “VERSION” in your Environment file
after generating your project environment file from the below step

cp example.env ~/gitops/erpnext-one.env
sed -i 's/DB_PASSWORD=123/DB_PASSWORD=changeit/g' ~/gitops/erpnext-one.env
sed -i 's/DB_HOST=/DB_HOST=mariadb-database/g' ~/gitops/erpnext-one.env
sed -i 's/DB_PORT=/DB_PORT=3306/g' ~/gitops/erpnext-one.env
echo 'ROUTER=erpnext-one' >> ~/gitops/erpnext-one.env
echo "SITES=\`one.example.com\`,\`two.example.com\`" >> ~/gitops/erpnext-one.env
echo "BENCH_NETWORK=erpnext-one" >> ~/gitops/erpnext-one.env

INTRODUCE A VERSION VARIABLE MANUALLY

# Reference: https://github.com/frappe/frappe_docker/blob/main/docs/images-and-compose-files.md

FRAPPE_VERSION=v14.21.0

# Only with ERPNext override
ERPNEXT_VERSION=v14.11.1
#For Custom Frappe app
VERSION=latest
DB_PASSWORD=123

Docker compose with custom override to generate the new yaml. Replace the project name

docker compose --project-name $project_name\
            --env-file ~/gitops/$project_name.env \
            -f compose.yaml \
            -f overrides/compose.erpnext.yaml \
            -f overrides/compose.redis.yaml \
            -f docs/compose/compose.multi-bench.yaml \
            -f docs/compose/compose.multi-bench-ssl.yaml \
            -f custom_app/compose.override.yaml config > ~/gitops/$project_name.yaml

Compose project up -d
Then it should go through.
Note if your are updating existing project ie from V13 to V14, You must populate the apps.txt manually with hrms.
Alternatively you can drop all the volumes including assets. You must take a copy of all the sites into your local directory and put back into sites folder again.
On a fresh container this will automatically populate

13

Thanks gsarunk. I’ll give this one a run and see how I make out. Appreciate it.
I found myself running around in circles looking.

1 Like
14

are there plans to add the bench get-app command into the official docker containers? We will start with ERPNEXT 13.xx because of the missing HR Module.

15

don’t use containers, they are immutable, you’ve to build new images to update or add apps.

you can use vm, native install, lxd or commonly discussed methods on forum.

conclusion: DO NOT use containers if you’re not already using them.

1 Like
16

Revant are you suggesting to avoid docker containers completely and just install direct? I find that’s more tangly when you’re already running multiple containers. My biggest issue right now is having multiple containers and the frappe_docker doesn’t seem to play well. The only version I’ve got up and running is the unprotected PWD test.

17

yes.

I think direct install is also a challenge. Check forum posts, everyday there is something related to installation bumped somewhere on posts.

Personally I don’t use anything from frappe_docker/docs.

For simple setups I use dockerswarm.rocks guide : ERPNext on Docker Swarm · GitHub Don’t use it! If frappe_docker didn’t work then the gist is not going to work.

For complex setups I use helm chart GitHub - frappe/helm: Helm Chart Repository for Frappe/ERPNext

For development I use vscode devcontainers. (frappe_docker/development)

That means I don’t use native direct installs in any case. I always prefer containers over native install.

Yet recently I installed on native on RHEL8 without internet connection: Frappe/ERPNext version 14 on RHEL 8 · GitHub

18

Interested on your RedHat install. We’re running a large server here which is why docker containers was good for us, keeps everything seperate. I have a small mini server which I could run separate and use specificially for this function. We don’t expose ourselves to the web here, everything is vpn so this version interests me as well.

Really, I’ve been up and running, I’m just having trouble integrating HRMS which without it, the program wouldn’t be useful.

Thanks for that information, guess weekend project for me.

19

@revant_one

Don’t get it. On the one hand you say:

don’t use containers, they are immutable, you’ve to build new images to update or add apps. you can use vm, native install, lxd or commonly discussed methods on forum.
conclusion: DO NOT use containers if you’re not already using them.

And on the other hand you say:

That means I don’t use native direct installs in any case. I always prefer containers over native install.

What now? What is your recommendation for future-proof production install?

Thanks,
Georg

20

Hi @GeorgBNM ,
I think this is a misunderstanding. What @revant_one was saying is that he is not using frappe_docker/docs at main · frappe/frappe_docker · GitHub for his/their installs, but instead based on the scenario Docker-Swarm or helm charts.

Maybe also see Container Basics

Docker Swarm is a native container orchestration tool for Docker. It allows you to create and manage a cluster of Docker nodes, and deploy and scale containerized applications across the cluster. It provides features such as automatic service discovery, load balancing, and service scaling. It is easy to set up and manage, and is well integrated with the Docker ecosystem.

Helm, on the other hand, is a package manager for Kubernetes. It provides a way to define, install, and upgrade complex Kubernetes application resources, such as pods, services, and ingresses, using a single configuration file called a Chart. Helm charts can be versioned, shared, and reused across teams and projects. It also provides a searchable repository of pre-built charts called Helm Hub. Helm is a more powerful tool than Docker Swarm, but it is also more complex to use, especially for teams that are new to Kubernetes.

In summary, Docker Swarm is a good choice for teams that are already using Docker and want a simple and easy-to-use orchestration tool, while Helm is a good choice for teams that are using or planning to use Kubernetes and want a powerful and flexible way to manage complex application resources.

1 Like
21

Hi @Patrick.St,

Thanks for the clarification.

Fighting for getting ERPnext up with docker on a Synology NAS.

Best,
Georg

22

Whole world is using containers. No sudden deprecation will happen, things are fairly predictable. Large community out there to learn from. If you enter the world of containers you’ll not be alone. Many applications available in container landscape.

Although with ERPNext + Containers you may feel alone, I do get many self-hosted success stories related to containers. Success stories don’t even make it to forum or issues! If container builds stop, or helm chart doesn’t get bumped, I’ll get issues on github suggesting active usage.

It is a great tool for developers to boostrap development as well!

Only requirement is you should know about containers or have an open mind to learn about containers.

Small container community here will keep them optimized and running for future.

1 Like
23

So going with containers is a solution, @revant_one?

Thank you!

Best,
Georg

24

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.