Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simplify dockerfile, parity with cedarish #15

Merged
merged 1 commit into from
Apr 7, 2015
Merged

Conversation

progrium
Copy link
Contributor

@progrium progrium commented Apr 3, 2015

This PR makes the Dockerfile pretty much exactly what progrium/cedarish is. It also makes it slightly smaller and eliminates the need to update the Dockerfile separately from the cedar-14.sh script.

My hope is that we can deprecate progrium/cedarish so that Dokku, Deis, Flynn, etc can start using this repo as the official base image. Cedarish has become a repository that just follows the cedar-14.sh script here and makes its own releases. If we can simplify the ecosystem and get all our base images closer to the authoritative source, all the better. :)

@JMSwag
Copy link

JMSwag commented Apr 5, 2015

+1

@tt
Copy link
Member

tt commented Apr 5, 2015

Can you provide some insight into why this change is required before you can use our Docker image?

@mboersma
Copy link

mboersma commented Apr 5, 2015

deprecate progrium/cedarish so that Dokku, Deis, Flynn, etc can start using this repo as the official base image

+1

@tt
Copy link
Member

tt commented Apr 6, 2015

Did you see my question, @progrium?

@progrium
Copy link
Contributor Author

progrium commented Apr 6, 2015

Because we match the environment as closely as possible. This is literally the Dockerfile cedarish uses. Although the previous one was roughly comparable, we don't want to risk them getting out of sync.

On top of that, it's best practice (despite what you may have seen, and what "makes sense" about caching) to have minimal layers and joining RUN commands. Especially for common base images. Especially if you remove any files.

Can you provide some insight into your hesitation?

@michaelshobbs
Copy link

+1

@josegonzalez
Copy link

+1 this would be lovely for us :)

@matthewmueller
Copy link

+1!

@tt
Copy link
Member

tt commented Apr 7, 2015

@progrium, the problem is that there shouldn't be a need to match the environment in the first place. Why don't you just use our published image?

If the way we build that image poses a practical concern, we can definitely have a discussion about changing it, but that doesn't seem to be the issue.

@progrium
Copy link
Contributor Author

progrium commented Apr 7, 2015

Shouldn't be a need to match the environment.... can you elaborate on that?

@tt
Copy link
Member

tt commented Apr 7, 2015

@progrium, instead of having two scripts be identical, it seems retiring the script wanting to be compatible with our version is the easier choice.

I probably need additional context, but couldn't you just replace these instances with heroku/cedar:14?

@progrium
Copy link
Contributor Author

progrium commented Apr 7, 2015

Having two scripts be identical? Are you talking about what cedarish is doing now? Yes, I agree! That is the point here.

I wouldn't use the current heroku/cedar:14 because knowing it comes from a separate build script makes it harder to trust that it represents the closest thing to production cedar. This PR is already a difficult move because we don't know if we can trust Heroku to care to keep this up to date and maintain it in a way that works for these downstream projects. This conversation is already showing maybe we can't.

@progrium
Copy link
Contributor Author

progrium commented Apr 7, 2015

That said maybe it's a style of communication problem. But I'm perceiving this as "being difficult without explanation". We propose improvements that happen to make it closer to what we want to use, you keep suggesting "why not just do it our way" without much explanation.

Maybe .... people are using heroku/cedar:14 already that expect it to be what it is today? That our changes somehow break compatibility? If that's the case, that's sort of exactly why we can't use it.

Maybe ... you don't want to care what the community thinks because this isn't a project you want to spend maintaining support for a wider community? You just want to do it the way you want and not care?

Maybe ... I don't know. See? I can't give you additional context without you sharing your additional context.

@tt
Copy link
Member

tt commented Apr 7, 2015

@progrium, I probably just misunderstood what you're trying to do. If all you're trying to do is to deprecate the other image that's great.

So, you want this pull request merged before making the switch because you're worried that we might not keep it up to date otherwise? That's a fair concern, although I can assure you that we will. I guess the answer is ultimately going to be trust. Even with the proposed change we could stop pushing changes to this repository.

What I thought you wanted was to increase the similarity between how your image is built and how we build ours. That's my concern. I don't want to make it any easier to produce more or less similar images; I want to have a single image so we will in fact be able to guarantee compatibility.

If this change is what you need for moving towards a single image instead of two images based on a single script, I'm fine merging it.

@progrium
Copy link
Contributor Author

progrium commented Apr 7, 2015

First off, this is great news. Second, I'll admit that the basic Herokuish smoke tests do pass when using the existing heroku/cedar:14.

However, besides trust and maintainability concerns, we do have concerns over how the Docker image is built.

First, as you know, we want it to be as close as possible to the production Heroku cedar stack. If the Docker image is built with a set of commands that are similar but not the same to cedar14.sh, that raises compatibility concerns. Though with trust and test coverage, maybe that's not as big a concern as it seems.

However, by actually using the same script, it makes it much more clear to everybody that it is as close as it can be. It also means that we know if you change cedar14.sh, that the Docker image will be updated at the same time. We could leave this to trust, but why allow the possibility human error when we can eliminate it? These are reasons for using cedar14.sh instead of recreating the commands. It's an implementation detail, yes, but it's an open source project and just seeing it be a different set of commands raises concerns. So this PR:

  • Builds trust with community
  • Eliminates possible human error

Next issue in how the Docker image is built. We have two related but separate concerns with Docker images. Size. And first time to download. Cedar14 is very big and seems it will only get bigger. To me this only increases the need to be as efficient as possible wherever we can. Right now, progrium/cedarish is slightly smaller than heroku/cedar. This PR makes heroku/cedar slightly smaller.

The bigger difference is first time to download. This is important because this is time needed with every new install of any platform based on cedarish. To us, every second counts. Although time to download seems directly tied to size, there are plenty of other factors. Dokku originally put an exported image on S3 (actually still does, but that will change) because Docker Hub used to be too slow and didn't compress layers. But the design of layers also makes a difference. There is slight overhead with each layer and the significant ones are not downloaded in parallel. Let me show you the difference between cedarish and heroku/cedar. Each of these are run after clearing all image/layer data to reproduce first time download:

$ time docker pull progrium/cedarish:latest
Pulling repository progrium/cedarish
18ca00a7e5b1: Download complete 
511136ea3c5a: Download complete 
5ca11046a9c8: Download complete 
d7334489ac75: Download complete 
73f05cf8ade0: Download complete 
Status: Downloaded newer image for progrium/cedarish:latest

real    1m16.602s
user    0m0.245s
sys 0m0.058s
$ time docker pull heroku/cedar:14
Pulling repository heroku/cedar
224cac1ffe3a: Download complete 
511136ea3c5a: Download complete 
5ca11046a9c8: Download complete 
d7334489ac75: Download complete 
8877df751d35: Download complete 
89d3077abdc4: Download complete 
3e2f1f361b22: Download complete 
91e4f466d3b0: Download complete 
125ef6ccee56: Download complete 
d00b3cf07dae: Download complete 
Status: Downloaded newer image for heroku/cedar:14

real    1m32.326s
user    0m0.258s
sys 0m0.060s

Obviously network speed introduces a huge variance, but cedarish consistently downloads faster than current heroku/cedar. Even though they are "more or less similar". But this is important to us.

So I think this explains all the reasons the changes in this PR are important to us, and why we think they should be important to you as well. :)

@tt
Copy link
Member

tt commented Apr 7, 2015

That's a solid case. Thank you for taking the time to submit this pull request and walk me through it. I can't wait to see you use our image.

@tt tt merged commit 4fd988e into heroku:master Apr 7, 2015
@progrium
Copy link
Contributor Author

progrium commented Apr 7, 2015

Very exciting. Thank you!

On Tue, Apr 7, 2015 at 11:53 AM, Troels Thomsen [email protected]
wrote:

Merged #15 #15.


Reply to this email directly or view it on GitHub
#15 (comment).

Jeff Lindsay
http://progrium.com

edmorley added a commit that referenced this pull request May 1, 2020
Since:
* The default reported by `locale` is `POSIX`, which is an alias of `C`:
  https://www.gnu.org/software/libc/manual/html_node/Standard-Locales.html
* There is no difference in the image contents with/without `LC_ALL=C`
  set, as confirmed by `container-diff diff --type file ...` (beyond the
  usual logs/fontcache/... differences).
* The env var was only set whilst `setup.sh` was being run, so has no
  effect on runtime usage of the stack-images.
* It was added to the stack-images repo in #15 without explanation, but
  seems to have been copied from here:
  https://github.com/progrium/cedarish/blob/967934e45d026fb2349422d50306ec462fc1789f/cedar14/Dockerfile#L3
  ...which itself was copied from the Ubuntu 12.10 usage here:
  progrium/cedarish@06b175d

I've not modified the Cedar-14 image, since it's EOL and has noisier
diffs in general when using container-diff, so not worth the effort to
vet.

Refs W-7496420.
edmorley added a commit that referenced this pull request May 5, 2020
Since:
* The default locale reported by `locale` is `POSIX`, which is an alias of `C`:
  https://www.gnu.org/software/libc/manual/html_node/Standard-Locales.html
* There is no difference in the image contents with/without `LC_ALL=C`
  set, as confirmed by `container-diff diff --type file ...` (beyond the
  usual logs/fontcache/... differences).
* The env var was only set whilst `setup.sh` was being run, so has no
  effect on runtime usage of the stack-images.
* It was added to the stack-images repo in #15 without explanation, but
  seems to have been copied from here:
  https://github.com/progrium/cedarish/blob/967934e45d026fb2349422d50306ec462fc1789f/cedar14/Dockerfile#L3
  ...which itself was copied from the Ubuntu 12.10 usage here:
  progrium/cedarish@06b175d

See also:
https://help.ubuntu.com/community/Locale

I've not modified the Cedar-14 image, since it's EOL and has noisier
diffs in general when using container-diff, so not worth the effort to
vet.

Refs W-7496420.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants