Dbt: Consider removing dbt_user from dbt's Docker image

[christippett]

Describe the feature

The Dockerfile definition for dbt creates dbt_user as the user to run subsequent commands under. This can cause issues when mounting volumes where the host filesystem is owned by root. The specific situation I'm thinking of is using the dbt Docker image as a build step in a CI environment, it's common for the files/directories in these environments to be owned by root, but the expectation is that build steps are still able to create directories and write files. Using the dbt Docker image in this context results in permission issues.

I'd like to suggest removing dbt_user from the image definition and using the default root user instead. Most Dockerized CLI tools I've come across do not specify an explicit user and use root as the default (refer: gcloud, doctl, busybox). Users using the image locally would be able to override the user at runtime using the --user flag if there was a desire or need to do so.

Describe alternatives you've considered

Our particular issue was using the dbt Docker image in Cloud Build. We were getting errors that dbt was unable to create the target/ and logs/ directories due to permission issues. We ended up having to run chmod -R 777 ./ on the working directory prior to running dbt to make things work. This was fine for us as the filesystem is ephemeral, but in other situations you obviously wouldn't want to do this (you'd also have access to the --user flag, which isn't an available option in Cloud Build).

Additional context

N/A

Who will this benefit?

This change would benefit users who use the dbt Docker image as part of their CI/CD pipeline. Having the image run under dbt_user imposes constraints that require workarounds that could ideally be avoided.

[beckjake]

This sounds really reasonable to me. I think the permissions change is just a regression from switching build systems, but I don't think there's any good reason to use dbt_user. It seems to cause a lot of trouble for end users and the upside is limited. I think the main advantage is it doesn't change all my local files to be owned by root when I run it in a mount, but I don't really use it enough to justify that.

@drewbanin how do you feel about me making this change for 0.17.1? It should be a pretty straightforward change to the dbt-release project's dockerfile. I could also cut an rc3 with just this change if we wanted to test it out.

[drewbanin]

@beckjake sure thing, I'm supportive of making a change like this in 0.17.1

[beckjake]

@christippett 0.17.1rc3 (just released) should run as root now. I would love it if you could give it a try sometime and let me know if it works as you expect.

[christippett]

Will do. Thanks for being so receptive to my suggestion and turning this around so quick 😊

[meurant-naude]

Hi there @beckjake,
Chris and I worked together so I thought I'd give you an update.
I've upgraded to 0.17.1rc3 and my testing would indicate that the issue has been resolved. @christippett might wanted to do testing on his end too to confirm my findings.
Cheers, Meurant

[dmateusp]

I just tested 0.17.1 and I was able to remove some work-arounds I had for permissions thank to the usage of root.

However, I'm seeing that fishtownanalytics/dbt:0.18.0b1 is using dbt_user again, any reason for it?

[beckjake]

0.18.0b1 was released on June 8th, 0.17.1 was released on July 20. The next 0.18.0 prerelease will use root.

[christippett]

@beckjake apologies for taking so long to get back to you. I can confirm I'm currently using the the dbt Docker image (tag 0.17.1rc4) in Cloud Build with no issues.