Answers: <p>As @Harith mentioned, the use of secrets simplifies deployments in various environments using environmental variables. To load in a secret directly use:</p>
  
  <blockquote>
    <p>$ kubectl create secret generic &lt; NAME OF SECRET > --from-literal=&lt; KEY >=abc123!:?  </p>
  </blockquote>
  
  <p>NOTE! This will put the secret in the Default namespace, add a namespace flag for specific resources e.g.:</p>
  
  <blockquote>
    <p>$ kubectl create secret generic mongodbsecret --from-literal=mongoUser=abc123!:? -n mongoNamespace</p>
  </blockquote>
  
  <p>You can then reference this secret in the deployment.yml or pod.yml or wherever you put your image for deployment on the kubernetes cluster.</p>
  
  <pre><code>env:
  - name: MONGO_INITDB_ROOT_USERNAME &lt;name of the env var in the code&gt;
     valueFrom:
       secretKeyRef:
         name: mongodbSecret &lt;NAME OF SECRET&gt; 
         key: mongoUser &lt;KEY&gt;
  </code></pre>
  
  <p>However, if all you need is to change 'development' to 'production' you could put an environment var directly in the (deployment).yaml.</p>
  
  <pre><code>env:
  - name: NODE_ENV
    value: production
  </code></pre>
  
  <p>You can also update the Jenkinsfile to send in the environment by for instance:</p>
  
  <pre><code>def resource_env = BRANCH_NAME == 'master' ? 'production' : 'development'
  
  sh "kubectl set env ${kubeImageName} NODE_ENV=${resource_env} --namespace ${kubeNamespace}"
  </code></pre>
  
  <p>On your current pipeline idea: The safest place for sensitive env vars would be putting it in kubernetes in a secret in your situation. However, for simple selection of deployment environments then using a Jenkinsfile simplifies things a bit like 'prod' vs 'dev'. Putting sensitive, variable or private things on git is a bad idea. Keep your docker images precise and task-orientated. </p>
  
  <p>Hope that helps</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-23T20:55:37.710Z
Answers: 2018-11-23T20:55:37.710Z
Answers: insidehustle
Answers: <p>The most important aspect you must consider when dealing with environment variables is <strong>security</strong>. So, no matter what, you don't want to expose the environment variables to the public by putting them out to, for example, github.</p>
  
  <p>Coming to your question, here is how you would use;</p>
  
  <p><strong><em>Docker</em></strong>:
  Make the docker take the values from the shell. So, in this case, you would need to use Jenkins to store your environment variables which will then be picked up by docker.</p>
  
  <p><strong><em>Kubernetes</em></strong>:
  Kubernetes provides an object known <code>Secrets</code>, so by using this object, you can store environment variables and then have them accessed via <code>Deployment</code> k8s object. <a href="https://kubernetes.io/docs/concepts/configuration/secret/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/configuration/secret/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-24T12:19:00.360Z
Answers: 2018-10-24T12:19:00.360Z
Answers: Harith
Body: <p>Because I am new in the DevOps, I don't know where I need to apply the changes to correctly run the project.</p>
  
  <p>The structure:</p>
  
  <p>Git → Jenkins → Docker build -> Kubernetes (deploy)</p>
  
  <p>Is it better to make the change of variables in the project, (example: password, database connection, etc.) to Jenkins, Kubernetes, or Docker?</p>
  
  <p>Example:</p>
  
  <p>With docker-compose I use an environment variable to change the variable inside my code.</p>
  
  <pre><code>environment:
    MONGO_INITDB_ROOT_USERNAME: user
    MONGO_INITDB_ROOT_PASSWORD: user
  </code></pre>
  
  <p>I want to change this variable and run correctly in the production environment.</p>
  
  <p>I don't know where it is the best to change the variable, Jenkins, Kubernetes with <a href="https://en.wikipedia.org/wiki/Ansible_(software)" rel="nofollow noreferrer">Ansible</a>, etc.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-10-23T23:26:06.257Z
Comments: Perhaps you can provide a concrete example with some code?  Your question is a little vague at the moment, so I'm not sure we can provide a good answer.
Comments: jayhendren
Tags: <jenkins><continuous-integration><kubernetes><jenkins-plugins>
Title: Change variable inside of project. Jenkins, docker, kubernetes
UserDisplayName: pioupiou
ThreadText: # Change variable inside of project. Jenkins, docker, kubernetes
  
  (Asked by: username_0 on 2018-10-23)
  
  Because I am new in the DevOps, I don't know where I need to apply the changes to correctly run the project.
  
  The structure:
  
  Git → Jenkins → Docker build -> Kubernetes (deploy)
  
  Is it better to make the change of variables in the project, (example: password, database connection, etc.) to Jenkins, Kubernetes, or Docker?
  
  Example:
  
  With docker-compose I use an environment variable to change the variable inside my code.
  
  ```
  environment:
    MONGO_INITDB_ROOT_USERNAME: user
    MONGO_INITDB_ROOT_PASSWORD: user
  
  ```
  
  I want to change this variable and run correctly in the production environment.
  
  I don't know where it is the best to change the variable, Jenkins, Kubernetes with [Ansible](https://en.wikipedia.org/wiki/Ansible_(software)), etc.
  
  **Tags:** jenkins, continuous-integration, kubernetes, jenkins-plugins
  
  > **Comments:**
  > **username_1**: Perhaps you can provide a concrete example with some code?  Your question is a little vague at the moment, so I'm not sure we can provide a good answer.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-11-23. Score: 1
  
  As @username_3 mentioned, the use of secrets simplifies deployments in various environments using environmental variables. To load in a secret directly use:
  
  > $ kubectl create secret generic < NAME OF SECRET > --from-literal=< KEY >=abc123!:?
  
  NOTE! This will put the secret in the Default namespace, add a namespace flag for specific resources e.g.:
  
  > $ kubectl create secret generic mongodbsecret --from-literal=mongoUser=abc123!:? -n mongoNamespace
  
  You can then reference this secret in the deployment.yml or pod.yml or wherever you put your image for deployment on the kubernetes cluster.
  
  ```
  env:
  - name: MONGO_INITDB_ROOT_USERNAME <name of the env var in the code>
     valueFrom:
       secretKeyRef:
         name: mongodbSecret <NAME OF SECRET> 
         key: mongoUser <KEY>
  
  ```
  
  However, if all you need is to change 'development' to 'production' you could put an environment var directly in the (deployment).yaml.
  
  ```
  env:
  - name: NODE_ENV
    value: production
  
  ```
  
  You can also update the Jenkinsfile to send in the environment by for instance:
  
  ```
  def resource_env = BRANCH_NAME == 'master' ? 'production' : 'development'
  
  sh "kubectl set env ${kubeImageName} NODE_ENV=${resource_env} --namespace ${kubeNamespace}"
  
  ```
  
  On your current pipeline idea: The safest place for sensitive env vars would be putting it in kubernetes in a secret in your situation. However, for simple selection of deployment environments then using a Jenkinsfile simplifies things a bit like 'prod' vs 'dev'. Putting sensitive, variable or private things on git is a bad idea. Keep your docker images precise and task-orientated.
  
  Hope that helps
  
  
  ---
  
  ### Answer by username_3 on 2018-10-24. Score: 0
  
  The most important aspect you must consider when dealing with environment variables is **security**. So, no matter what, you don't want to expose the environment variables to the public by putting them out to, for example, github.
  
  Coming to your question, here is how you would use;
  
  ***Docker***:
  Make the docker take the values from the shell. So, in this case, you would need to use Jenkins to store your environment variables which will then be picked up by docker.
  
  ***Kubernetes***:
  Kubernetes provides an object known `Secrets`, so by using this object, you can store environment variables and then have them accessed via `Deployment` k8s object. <https://kubernetes.io/docs/concepts/configuration/secret/>
  
  
  ---
  
  