NodeJS hot reload issue #261
Comments
|
The way colima binds host directories into the guest VM means that certain filesystem events are not observed / generated. You can work around this by using |
|
Hello, thank you for your answer. The legacy is a workaround, but unfortunately in my use case it's very slow and use a lot of cpu. It's not the best, but for now when I finished to edit my code I "touch" the entrypoint of the application.
|
|
I'm facing the same issue with |
I am working on a workaround taking a similar approach to #261 (comment) while leveraging inotify. I paused due to some issues with the Go library at the time, but I will revisit it. |
It would be great to have this feature completed. Is there a work-in-progress branch that I could possibly help continue/test? |
|
Hi, is there any progress on that? If you need some help, I may push our development team to help you. We need this so our frontend team could work using colima. Docker for mac is not an option for us) |
|
@djirik support for virtiofs mounts is imminent and would be part of the next release. It has been merged into master upstream in Lima and currently being integrated and tested in Colima, the early results have been quite impressive. Virtiofs is same tech used by Docker Desktop for the fast volume speeds. |
|
@abiosoft thank you very much |
|
@abiosoft Hi, do you have an idea when would it be available? |
|
@djirik within the next week or two #497 (comment). You can actually test it now |
|
@abiosoft hi again, I've succesfully switched to virtiofs on macOs 13. However
|
@djirik hmmm 🤔 did you reset. i.e. Is your project something that I can try to reproduce? I have tested with a number of development environments that provides live reload and it has worked fine. |
|
@djirik also, kindly confirm |
|
@abiosoft I can ask frontend team if they can make sample project without production code. |
|
@abiosoft I have recreated colima again just to be sure, seems like it changed things a bit, now I'm having a lot of permission/access rights errors, I will fix it and return with more feedback. |
|
@abiosoft File permissions are hell with virtiofs. I can't even launch node project with volume mounts. Can not figure out how to set user:group in compose file. |
Do you have an idea of the userId in the container? You can check by running |
version: '3.9'
services:
nuxt:
build:
dockerfile: ../docker/nuxt/Dockerfile
context: ./source
target: node_base
image: ${NUXT_IMAGE_NAME:-localhost/nuxt}:${NUXT_IMAGE_TAG:-latest}
# user: $DEV_LOCAL_UID:$DEV_LOCAL_GID # here I've tried 501:20, 1000:1000, 501:1000, 0:0
restart: 'no'
environment:
FORCE_COLOR: '1'
NPM_TOKEN: $NPM_TOKEN
entrypoint: sh
command:
- -xec
- |-
npm run npm-auth-repo --loglevel verbose
npm install --loglevel verbose
npm run dev --loglevel verbose
volumes:
- ./source:/app
- ./volumes/nuxt/HOME:/home/nodeFROM node:16.17.1-alpine AS node_base
WORKDIR /app
ENV HOST 0.0.0.0
EXPOSE 3000Everytime I'm getting either 243 error from node, or permission denied for creating files in |
|
@djirik as an unrecommended stopgap, the permission denied error should go away if you run Give me a moment, let me try to reproduce your error using the |
|
@djirik out of curiosity, why is |
|
@abiosoft I've tried with 777, but it didn't have any effect. Yes, |
|
@djirik I am unable to reproduce your permission issues. You can send me an email at the email on my GitHub profile and we can schedule a session to troubleshoot this. As for the hot reload issue, I can confirm it is not yet fixed with virtiofs. Apparently, I was testing with a dotnet project and it works fine, and thereby assumed it catered for all other environments (including the node stack) as well. |
|
I can confirm that also on my nodejs project mounted volumes are not "touched" in the container. I encounter no permission issues though.
|
|
@codingluke what is your node version? can you please share you Dockerfile and docker-compose? |
|
@abiosoft I have sent you an email |
|
@djirik I use the latest 18.12.1. It is a docusaurus/marp project.
|
|
@codingluke I get it now, you are not mounting sources and NODE_HOME into container, this is why you don't have permission issues I guess. |
|
correct and I would recommend to only mount the part which is edited locally. I don't see the need to share node_modules and co. For persistence I would use docker volumes. Of course there might be some reason to do it differently. |
|
@abiosoft I have skipped mounting /home/node, as it was found unnecessary, but hot reload is still not working :(. The working behavior is like this:
Can we steal something from |
|
@abiosoft Sure! The log that I see is as follows: This error message stood out to me: When I try to run and when I do
I'm not sure if that error message is a red herring or not, but it seems to be happening because Interestingly it does show that the daemon is noticing the events, they're just not making it into my container 🤔 |
The error is expected initially until the startup is complete. Also, the context is preserved (via env vars) and it is not running in the default instance but simply showing the commands being used. What kind of project are you running? |
Gotcha! Thanks for explaining
For this test, I'm just running a one off container started with I also checked and confirmed that I'm seeing this for both qemu + sshfs and vz + virtiofs (I was wondering if using virtiofs might be contributing) |
|
@michaeldiscala this solution is not actually propagating inotify events from the host, it's a workaround to simulate the behaviour. Probably why the inotify tools are not picking it up. In fact, the goal is to provide the "hot reload" developer experience, rather than inotify events. |
|
Ah gotcha @abiosoft, thanks for explaining! Looking through the patch itself some more, I realized that you're passing the event through by running a When I update my test to listen to all inotify events (instead of just modification events like in my original run): I see events coming through as expected: It's just that all of the modifications come in as |
|
hello guys, can someone help me, i got some error. colima 0.5.4 already installed
|
|
@rffensick you need the HEAD version of colima ( |
|
@matleh thank you! |
|
after updating and trying to start all of the containers that I have in my project, I have almost all of the containers exit with error 139 I can share more information if you tell me what to do
|
|
start colima with command: but works with |
|
With the amount of positive feedbacks received so far, a release would be made soon. Thanks. |
|
Works on my machine, too. |
|
I am using the HEAD of Colima and it still doesn't seem to be working for me. I can edit files in the container and my watchers will detect the changes, but not if I edit files in my IDE. Any assistance is appreciated! 
Here is my config # Number of CPUs to be allocated to the virtual machine.
# Default: 2
cpu: 4
# Size of the disk in GiB to be allocated to the virtual machine.
# NOTE: changing this has no effect after the virtual machine has been created.
# Default: 60
disk: 100
# Size of the memory in GiB to be allocated to the virtual machine.
# Default: 2
memory: 6
# Architecture of the virtual machine (x86_64, aarch64, host).
# Default: host
arch: host
# Container runtime to be used (docker, containerd).
# Default: docker
runtime: docker
# Kubernetes configuration for the virtual machine.
kubernetes:
# Enable kubernetes.
# Default: false
enabled: false
# Kubernetes version to use.
# This needs to exactly match a k3s version https://github.com/k3s-io/k3s/releases
# Default: latest stable release
version: v1.25.4+k3s1
# Disable k3s features [coredns servicelb traefik local-storage metrics-server].
# All features are enabled unless disabled.
#
# EXAMPLE - disable traefik and metrics-server
# disable: [traefik, metrics-server]
#
# Default: [traefik]
disable:
- traefik
# Auto-activate on the Host for client access.
# Setting to true does the following on startup
# - sets as active Docker context (for Docker runtime).
# - sets as active Kubernetes context (if Kubernetes is enabled).
# Default: true
autoActivate: true
# Network configurations for the virtual machine.
network:
# Assign reachable IP address to the virtual machine.
# NOTE: this is currently macOS only and ignored on Linux.
# Default: false
address: false
# Custom DNS resolvers for the virtual machine.
#
# EXAMPLE
# dns: [8.8.8.8, 1.1.1.1]
#
# Default: []
dns:
- 8.8.8.8
# DNS hostnames to resolve to custom targets using the internal resolver.
# This setting has no effect if a custom DNS resolver list is supplied above.
# It does not configure the /etc/hosts files of any machine or container.
# The value can be an IP address or another host.
#
# EXAMPLE
# dnsHosts:
# example.com: 1.2.3.4
dnsHosts: {}
# Network driver to use (slirp, gvproxy), (requires vmType `qemu`)
# - slirp is the default user mode networking provided by Qemu
# - gvproxy is an alternative to VPNKit based on gVisor https://github.com/containers/gvisor-tap-vsock
# Default: gvproxy
driver: gvproxy
# ===================================================================== #
# ADVANCED CONFIGURATION
# ===================================================================== #
# Forward the host's SSH agent to the virtual machine.
# Default: false
forwardAgent: false
# Docker daemon configuration that maps directly to daemon.json.
# https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file.
# NOTE: some settings may affect Colima's ability to start docker. e.g. `hosts`.
#
# EXAMPLE - disable buildkit
# docker:
# features:
# buildkit: false
#
# EXAMPLE - add insecure registries
# docker:
# insecure-registries:
# - myregistry.com:5000
# - host.docker.internal:5000
#
# Colima default behaviour: buildkit enabled
# Default: {}
docker: {}
# Virtual Machine type (qemu, vz)
# NOTE: this is macOS 13 only. For Linux and macOS <13.0, qemu is always used.
#
# vz is macOS virtualization framework and requires macOS 13
#
# Default: qemu
vmType: vz
# Utilise rosetta for amd64 emulation (requires m1 mac and vmType `vz`)
# Default: false
rosetta: true
# Volume mount driver for the virtual machine (virtiofs, 9p, sshfs).
#
# virtiofs is limited to macOS and vmType `vz`. It is the fastest of the options.
#
# 9p is the recommended and the most stable option for vmType `qemu`.
#
# sshfs is faster than 9p but the least reliable of the options (when there are lots
# of concurrent reads or writes).
#
# Default: virtiofs (for vz), sshfs (for qemu)
mountType: virtiofs
# Propagate inotify file events to the VM.
# NOTE: this is experimental.
mountInotify: true
# The CPU type for the virtual machine (requires vmType `qemu`).
# Options available for host emulation can be checked with: `qemu-system-$(arch) -cpu help`.
# Instructions are also supported by appending to the cpu type e.g. "qemu64,+ssse3".
# Default: host
cpuType: ""
# For a more general purpose virtual machine, Ubuntu container is optionally provided
# as a layer on the virtual machine.
# The underlying virtual machine is still accessible via `colima ssh --layer=false` or running `colima` in
# the Ubuntu session.
#
# Default: false
layer: false
# Custom provision scripts for the virtual machine.
# Provisioning scripts are executed on startup and therefore needs to be idempotent.
#
# EXAMPLE - script exected as root
# provision:
# - mode: system
# script: apk add htop vim
#
# EXAMPLE - script exected as user
# provision:
# - mode: user
# script: |
# [ -f ~/.provision ] && exit 0;
# echo provisioning as $USER...
# touch ~/.provision
#
# Default: []
provision: []
# Modify ~/.ssh/config automatically to include a SSH config for the virtual machine.
# SSH config will still be generated in ~/.colima/ssh_config regardless.
# Default: true
sshConfig: true
# Configure volume mounts for the virtual machine.
# Colima mounts user's home directory by default to provide a familiar
# user experience.
#
# EXAMPLE
# mounts:
# - location: ~/secrets
# writable: false
# - location: ~/projects
# writable: true
#
# Colima default behaviour: $HOME and /tmp/colima are mounted as writable.
# Default: []
mounts: []
# Environment variables for the virtual machine.
#
# EXAMPLE
# env:
# KEY: value
# ANOTHER_KEY: another value
#
# Default: {}
env: {} |
|
I'm testing colima 0.5.5 with this experimental My setup (with which I currently use Docker Desktop ...) happens to use reflex and it (reasonably?) which seems to ignore these attribute/mode changes, waiting for some file contents change: ... I wonder if this is part of the design of how the fs events simulated/triggered inside the VM? Is it hard to change? (I also notice that "rm" (unlink) and "touch" (ctime) are not propagated, but that is probably OK for my use-case ...) Here's the Docker Desktop inotify event emulation to compare: and for reflex (slightly modified command but doesn't matter): Anyway, much thanks for what you've made with colima thus far, and I hope this report may help either improve or clarify the inotify feature in the future 😁 |
|
Hi, I have the same issue with @ploxiln . It doesn't work when I use reflex in docker-compose command. |
|
Hi @abiosoft - Is |
@chrismith-equinix docker containers with mounted volumes are monitored, so it should work if the Kubernetes pod has a mounted volume. |
|
Great thanks @abiosoft ... We are using containerd runtime instead of docker. It should work with containerd images as well? |
Having looked at the implementation, I can see that only the |
|
@chrismith-equinix can you kindly create another issue for that? Thanks. |
|
I would be closing this issue as I think it has outlived it's purpose. Anyone is free to create new issue(s) for the remaining use cases that are yet to be covered. Thanks to everyone that has contributed so far. |
|
@abiosoft - My workloads are not running in the Thanks for looking into this, and the timely response. It is appreciated |
and others
Kindly jump to #261 (comment) for most recent update.
Hello,
I switched from Docker Desktop to Colima. I noticed an issue with "watcher" on bind volume. I created a repository: https://github.com/shenron/colima-hot-reload-issue
The container is not able to see when a file has been updated. But if I touch the file from the container it works. I guess it's linked to the volume.
I'm using the Macbook Pro M1 Max with:
The text was updated successfully, but these errors were encountered: