News for hackers. Stuff that matters.

A comment on Maybe You Don't Need Kubernetes. Parent comment

Re:Maybe You Don't Need Kubernetes by nickbauman on Friday March 22, 2019 @10:14PM (#19468640)
Managed k8s or Heroku? I don't understand why people don't try to do AppEngine. It's the oldest "Serverless" platform out there and wickedly mature. If you're worried about vendor lock in (and you should be) I have deployed AppEngine apps on the F/OSS AppScale unmodified.
[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by ngrilly on Saturday March 23, 2019 @10:23AM (#19470548)
> I have deployed AppEngine apps on the F/OSS AppScale unmodified.

How did you manage secrets on Google App Engine?

[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by nickbauman on Wednesday March 27, 2019 @05:47PM (#19506423)
In the flex environment you can inject secrets at container build time. In App Engine standard I've used a deploy wrapper around ansible vault to do it.
[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by ngrilly on Thursday March 28, 2019 @08:26AM (#19511476)
> In the flex environment you can inject secrets at container build time.

Does it mean your secrets are stored in plain text in the container image?

> In App Engine standard I've used a deploy wrapper around ansible vault to do it.

What does the deploy wrapper do? Does it produces an app.yaml file with the secrets injected in it, after having been decrypted by Ansible Vault?

[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by nickbauman on Thursday March 28, 2019 @10:36AM (#19512575)
Q: Does it mean your secrets are stored in plain text in the container image?

A: No. It means the secrets are stored as environment variables in the container.

Q: What does the deploy wrapper do?

A: It prompts the developer to input the ansible vault password , decrypts the vault and injects the secrets into the environment.

Generally speaking, I follow the 12-factor approach:

https://12factor.net/

[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by ngrilly on Thursday March 28, 2019 @12:30PM (#19513773)
What do you mean by "injecting secrets into the environment"?

You mean a section in your app.yaml like this one:

    env_variables:
      DB_PASSWORD: "this is a secret"
As for as I know, in the Standard and Flex environments, app.yaml is the only way to define environment variables.
[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by lugg on Saturday March 23, 2019 @02:31AM (#19469317)
Why should you be concerned about vendor lock in?

I haven't heard a convincing argument why vendor lock in is a problem regarding the cloud.

It can be a problem, but all solutions result in you avoiding the things you went there for in the first place.

There is exceptions to this obviously but I find most people worried about vendor lock in are no where near big enough to bother running multi cloud.

[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by neop1x on Monday March 25, 2019 @09:07AM (#19482125)
because you have to agree with every change vendor make. If they double pricing, you pay twice. If they ban service type you host, you have to stop. If they make an incompatible change in some of the hosted parts, you have to adapt. If you grow too much they refuse to allocate you more resources or it is expensive for you to use them at your scale, it is difficult to migrate away. That is vendor lock in -> loss of freedom and choice.
[ Parent | on HN ]
Re:Maybe You Don't Need Kubernetes by nickbauman on Wednesday March 27, 2019 @05:53PM (#19506473)
neop1x has a great response. A more concrete example would be a gaming company that started out with AppEngine for its server support for the game. Once the game has a proven revenue stream, the economics of moving from AppEngine to AppScale are a critical next step to maximizing ROI. You have all the code, now you just need to host it somewhere. Can't do that with any other serverless Platform.

It's important to note that AppScale is an aPaaS, and API-platform-as-a-service, where you're guaranteed a consistent API with the ability to plug in different implementations. Something even beyond your typical openness in F/OSS software, too.

[ Parent | on HN ]