dbt-core: [CT-284] [Bug] Unable to run dbt inside a docker container due to missing dependencies
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Running dbt deps inside a Dockerfile has no effect on the final resulting image. This is pretty much a full blocker for me, and I feel like I’m going crazy that this isn’t already an issue anyone has raised. I must be missing something obvious, right?
Expected Behavior
Running dbt deps should persist the generated dbt_packages in the final resulting image. Immutable deploys are super important so you know exactly what you’re getting every time you ship code. This means the deps are bundled in the image at build time. That way if anything is down (like the servers where the dbt dependencies are hosted), my image still has everything it needs inside it to start up. Or, if I need to ship the exact same image again, I can.
Steps To Reproduce
Set up this docker file:
FROM ghcr.io/dbt-labs/dbt-core:1.0.latest
RUN pip install dbt-snowflake
COPY / ./
RUN dbt deps
ENTRYPOINT ["dbt", "--log-format", "json", "--warn-error", "run"]
The resulting image will not contain the dbt_packages directory, even though the dbt deps command was run. For example:
❯ docker run -it --entrypoint=/bin/sh my-image:my-tag
# ls
dbt_project.yml models seeds tests
analyses macros packages.yml snapshots
#
There is no dbt_packages directory.
Relevant log output
17:09:24 + docker build -t <my-company-jfrog-url>:2022-02-24.43-83023aa-rel -f Dockerfile .
17:09:24 Sending build context to Docker daemon 600.1kB
17:09:24 Step 1/5 : FROM ghcr.io/dbt-labs/dbt-core:1.0.latest
17:09:24 ---> afbbb0909dea
17:09:24 Step 2/5 : RUN pip install dbt-snowflake
17:09:24 ---> Using cache
17:09:24 ---> 218706b2f74e
17:09:24 Step 3/5 : COPY / ./
17:09:25 ---> 614cce69e3d8
17:09:25 Step 4/5 : RUN dbt deps
17:09:25 ---> Running in 2b9fc7ee9938
17:09:27 22:09:27 Running with dbt=1.0.2
17:09:28 22:09:28 Installing dbt-labs/dbt_utils
17:09:29 22:09:28 Installed from version 0.8.1
17:09:29 22:09:28 Up to date!
17:09:29 22:09:28 Installing calogica/dbt_expectations
17:09:29 22:09:29 Installed from version 0.5.1
17:09:29 22:09:29 Updated version available: 0.5.2
17:09:29 22:09:29 Installing calogica/dbt_date
17:09:29 22:09:29 Installed from version 0.5.3
17:09:29 22:09:29 Up to date!
17:09:29 22:09:29
17:09:29 22:09:29 Updates available for packages: ['calogica/dbt_expectations']
17:09:29 Update your versions in packages.yml, then run dbt deps
17:09:30 Removing intermediate container 2b9fc7ee9938
17:09:30 ---> 1420e054b93a
17:09:30 Step 5/5 : ENTRYPOINT ["dbt", "--log-format", "json", "--warn-error", "run"]
17:09:30 ---> Running in 9a6e49e3fe2a
17:09:31 Removing intermediate container 9a6e49e3fe2a
17:09:31 ---> aa6f5ca2bcba
17:09:31 Successfully built aa6f5ca2bcba
17:09:31 Successfully tagged <my-company-jfrog-url>:2022-02-24.43-83023aa-rel
Environment
- OS:
- Python:
- dbt:
What database are you using dbt with?
No response
Additional Context
other folks are having the same issue: https://getdbt.slack.com/archives/C2JRRQDTL/p1645743857126709
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 30 (22 by maintainers)
at the very least, hopefully this issue serves as a searchable destination for users debugging the same weird behavior
@alexrosenfeld10, thanks a lot, works fine!
Btw, I tested this a tiny bit further - it definitely is because of the
VOLUMEstatement. Any files created in a dockerVOLUMEas a result of aRUNcommand during the build process aren’t allowed to persist:Then, playing around in the resulting container:
test.txtis nowhere to be found.Yeah, I’m fried too I’ve been working on this issue all day haha. I hope we can get a consistent reproduction. Using the different directory seems to work, and I got my first successful deployed run of dbt with it so that’s at least something! Thanks again for the help.