.dockerignore being ... ignored?

Questions / Help Build debugging
#1

I’m having trouble excluding files for deployment with a .dockerignore. I’ve validated that files are excluded if I locally build a docker using this Stackoverflow answer.

But when I run flyctl deploy --remote-only , the excluded files and directories still end up on the app server. For example, the whole .git/ folder is sent, .env.local is sent, etc.

This worked for me earlier and I’m not sure what has changed.

I’m running on an M1 Mac, flyctl v0.0.303 darwin/arm64

Here is my .dockerignore (I was playing with variations of the * for .env).

Why is it not excluding .env.local and the .git/ tree? Any suggestions how to debug?

**.env**
.env.*
!.env.prod
ops/*
.git/**
**/node_modules
.next/*
**.DS_Store
**.vercel
.idea/
next-env.d.ts`
#2

I have seen various people report issues when using an M1 Mac, all related to Docker. Hmm.

One thing you could maybe try is what I do in my .dockerignore file. Which is to exclude everything and then only add back things you know you need deploying. Doing that automatically skips the git folder, and any other thing that may accidentally get added. The approach works like this (in the case of a node app). So it inverts it, using the ! in step 2:

# 1. Ignore everything
**

# 2. Add files and directories that should be included
!public/**
!src/**
!package.json
!package-lock.json

# 3. Bonus step: ignore any unnecessary files that may be inside those allowed directories in 2
**/*~
**/*.log
**/.DS_Store
**/Thumbs.db
#3

We use the same “code path” as Docker to parse exclusions from .dockerignore.

@BobalsDelicious You mentioned this worked before? Was it the same .dockerignore?

This could be a regression in a newer version of flyctl.

#4

@jerome I thought about a potential regression too. I rolled back to flyctl v0.301 (found the old flyctl brew file and invoked it locally) but am still experiencing the same issue.

Inspired by @greg , I also changed my .dockerignore to just:

**

and the thing still built and all files are still on the server(!) . Deploy command is flyctl deploy --remote-only

In other words, the .dockerignore is not being picked up. I must have something basic wrong but I can’t figure out what.

Fly.toml contents in case it helps:

app = "my-app"

kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[build]
  builder = "heroku/buildpacks:20"

[env]
  PORT = "8080"

[experimental]
  allowed_public_ports = []
  auto_rollback = true

[[services]]
  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"
#5

Did it previously work without a buildpack? I think that might be the issue in flyctl. I’m looking into that now.

#6

Thanks so much for looking at this.

I didn’t intentionally create a buildpack, this is what flyctl launch created. I don’t think the config changed.

I just re-created a minimal new fly app and launched it, and still have the issue. Here’s my command sequence:

mkdir 3 && cd 3
echo "fly.toml" > .dockerignore
echo '{ "scripts": { "build": "next build", "start": "next start" } }' > package.json
npm i next
mkdir pages
flyctl launch

In flyctl I chose:

  • Name: auto-gen
  • Region: IAD
  • Create a DB: no
  • Deploy now: yes

Expected: fly.toml should not be present in /app/ directory when examined with flyctl ssh console because of the .dockerignore entry.
Got: fly.toml is present

Are you able to repro that?

(BTW it’s so cool that it’s so easy to spin up an app!)

#7

I have fixed the issue and released a new flyctl version (0.0.304). If you upgrade and deploy again, it should work as intended.

1 Like
#8

Wow thanks for the support. You guys are going to rule the world if you can remain this responsive as you grow :slight_smile:

It did fix it indeed. I must have been wrong about this working previously?

Is the underlying issue this?