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

Allows to define hostAliases for all pods #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

webmatze
Copy link

For my use-case of cuber I need to be able to define hostAliases to be able to access some external services by hostname.

Kubernetes provides this functionality: https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/

This PR allows to define multiple hostAliases in your Cuberfile.

Example:

app 'test'
repo '.'
dockerfile 'Dockerfile'
dockerconfig 'config/dockerconfig.json'
image 'my/image-name'
hostalias '1.2.3.4', hostnames: ['my-external-service.hostname']
proc :web, 'bundle exec rails s'

Maybe you'll find this useful or have any requests for changes.

Thank you again for this amazing gem. 😄

@collimarco
Copy link
Contributor

Hello!

Thank you very much for your contributions!

The idea is that Cuber will have feature parity with common PaaS, like Heroku, Render, DigitalOcean App Platform, etc. Thus Cuber will have only a subset of the Kubernetes features (otherwise, after some years of development, we would just have an alternative syntax for the K8s YML files, and this is not the aim of this project).

Since you can run almost all kinds of apps on a PaaS, when there isn't a feature available in Cuber, there is usually an alternative way to implement the same feature inside the application code.

For example, in this case, have you considered using an env variable to pass the IP address to your application?

@webmatze
Copy link
Author

Thank you @collimarco for taking the time.
I can see what the reasoning behind your answer is.

Unfortunately, for my use-case I am not using a PaaS but a self hosted Rancher instance. Which has some differences to a normal Kubernetes cluster anyway. (eg. projects)

You are right, it should be possible to work around the hostalias problem by using env variables.

But I need the --build-arg feature to fully use the Dockerfile support provided by cuber.

Another problem is the namespace functionality of cuber. As Rancher supports namespaces in projects, which is not possible to use in cuber at the moment without a workaround. (I have to create the namespace outside of cuber)

So as you can see, I really want to use a tool like cuber, but there are a lot of workarounds needed for me to make it work at the moment.

@collimarco
Copy link
Contributor

Thanks for the details! @webmatze

Would the --build-arg feature alone make it possible for you to use Cuber? Or there are many other differences and features required to support Rancher and your specific environment? Have you already made a successful deploy using Cuber in your environment?

@webmatze
Copy link
Author

webmatze commented Aug 31, 2022

Yes, the --build-arg feature is needed for me to sussessfully deploy my application to Kubernetes.
And yes, I was able to successfully deploy it using my fork of cuber. 👍

I was thinking about a way in cuber to allow the customization of the whole deployment process.
One way could be to provide before and after hooks in cuber.

So I could use something like the following to create a namespace in rancher:

# Cuberfile
...
before(:apply) do |cuber_options|
  my_rancher_client "namespace create #{cuber_options[:app]}"
end
...

What do you think?

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.

2 participants