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

Preferred method of including runtime binaries that are not available in aptitude #21

Open
zgohr opened this issue Feb 20, 2019 · 2 comments

Comments

@zgohr
Copy link

zgohr commented Feb 20, 2019

According to this discussion which I agree with the premise of, there is no way to have Distillery include 3rd party binaries in a release.

That leaves me needing to modify the runtime to include wkhtmltopdf with my project, and the latest available package for Ubuntu 16 is 0.12.2.4 and I require the latest, 0.12.5.

Although I'm not sure exactly how, it seems I should be able to create a custom Dockerfile from this runtime stack and use it as a custom runtime. It would be fantastic to understand how to accomplish this, but I haven't tried this route yet.

The hack I have in place for now is to do it with a nasty entrypoint. This is undesired for a multitude of reasons.

runtime_config:
  packages:
    - wget
    - xfonts-75dpi
    - xfonts-base

entrypoint: wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox_0.12.5-1.trusty_amd64.deb && dpkg -i wkhtmltox_0.12.5-1.trusty_amd64.deb && /app/bin/myapp foreground

Is there currently a better way to accomplish this that wouldn't require creating a custom runtime?

@zeroasterisk
Copy link

Yes - you should do this in your Dockerfile and build up a custom image.

You can do that for GAE by setting up your own build:
http://go/gh/GoogleCloudPlatform/elixir-runtime/blob/master/runtime-build.sh

Or you can instead decide to host your payload on Google Kubernetes Engine.
https://cloud.google.com/community/tutorials/elixir-phoenix-on-kubernetes-google-container-engine

@zgohr
Copy link
Author

zgohr commented Mar 11, 2019

Thanks, @zeroasterisk. What I'm hearing is I could fork this repository, making necessary modification in, for example, within the Dockerfile generator template Dockerfile-release.eex and use runtime-build.sh to put this customized runtime into Google Storage for use by my project.

What is the opinion of adding a runtime_scripts section, similar to build_scripts? I know this project likely needs to follow a more generic app engine project template - but if the flexibility exists and it sounds like a good idea, I'd be happy to add it.

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

No branches or pull requests

2 participants