what is the reason that the docker-sdk generator uses json_encode() to encode the project secrets? I

U010DNAA3QW

what is the reason that the docker-sdk generator uses json_encode() to encode the project secrets? I have a secret like MY_SECRET: "abc/def" and this ends up like MY_SECRET: "abc\/def" in the env file being generated because of this, which of course is a different value

U010DNAA3QW

see https://github.com/spryker/docker-sdk/blob/2b49cb456a6793f806ceb3125d8508267c9e4a85/generator/index.php#L42 and https://github.com/spryker/docker-sdk/blob/2b49cb456a6793f806ceb3125d8508267c9e4a85/generator/src/templates/env/common.env.twig#L30

U010DNAA3QW

should I always json_decode() the secret env variables in my application?

U010DNAA3QW

I am currently mis-using the secrets to set some env variables inside of the containers (e.g. COMPOSER_HOME), is there then another solution available for this?

Unknown

@ULYHPR789?

sprymiker

Hi Rene,

Where do you set MY_SECRET value for docker/sdk to catch it up?

U010DNAA3QW

@ULYHPR789 in the deploy.yml under project:secrets

sprymiker

1. It is abuse of wrong-named internal intermediate variable.
   And anyway according the code:

$projectData['secrets'] = buildSecrets($deploymentDir);

It will be overridden with auto-generated secrets.
How does it work for you?

2. Secrets MUST NOT be defined in deploy.yml. We have a feature in backlog that will allow to declare secrets and pass it from env.

3. To solve your particular issue use the following:

image:
  tag: spryker/php:7.3
  environment:
    COMPOSER_HOME: blah blah

That will embed env variable into image. And again this cannot be used for secrets.

U010DNAA3QW

hey @ULYHPR789 I am not talking about $projectData['secrets'], I am talking about $projectData['project']['secrets'] (the YAML definition is project:secrets:, not top-level secrets:), they are being parsed by generator/src/templates/env/common.env.twig: {% for secretKey, secretValue in project['secrets'] %}
it is definitely working for me, the values I set there are being added to the generated .env files. So this is a "wrong-named internal intermediate variable", yes? I should not use it? How should I do it then? 😄 Currently not possible, because of your second point?
And regarding image:environment: thanks! This sounds definitely like a better solution. But why do you suggest it should also not be used for secrets? Because it is not secret? 😄

sprymiker

Thanks for finding this caveat. It should not work that way.

U010DNAA3QW

oh okay 😄

sprymiker

Secrets must be secured. And deploy.yml should be committed into a repo. And that is not so secure. Secrets must be passed only in runtime. And we have only support for internal secrets only for now.

U010DNAA3QW

thank you @ULYHPR789!!! 🙂 Looking forward to the new feature with being able to store secrets correctly, until now I will use a workaround 🙂

s.kroll

I'm already looking forward to this. I think it would be fine for many (local / development) cases to have a .env (if existing and maybe with environment naming scheme like .env.stage .env.prod) automatically been included while docker/sdk boot. the variables from this file should end up in the different {service}_{store}.env files in /docker/deployment/default/env/

sprymiker

@UPZH5HHEV Please, register this as an idea. Thanks.

s.kroll

Little bit late, but here it is: https://spryker.ideas.aha.io/ideas/CUSTIDEAS-I-140