DB_HOST is used by apps such as the realworld.io laravel demo app about laravel-ex

[J5Dev]

Hi did you get a resolution for this not working, as I am having the same problem, but using my own app... basically using this template migrations fail as the DB cannot be reached.

Is it as simple as adding the following to the env section?

{ "name": "DB_SERVICE_NAME", "value": "${DATABASE_SERVICE_NAME}" },

[simbo1905]

@J5Dev The working env vars are shown here: https://github.com/simbo1905/laravel-realworld-example-app/blob/master/.env.example

If you use those settings it will work.

I don't like having the settings outside of a secret. So once you have it working you can upgrade to load the settings into a secret that is loaded into the deployment.

here is where I mount the secret as the environment of the deployment https://github.com/simbo1905/laravel-realworld-example-app/blob/1a6c256a36a831dd56dc655cd015073b1cbecdbd/openshift-template.json#L182 it uses $NAME so the name of the secret has to match the name of the deployment which is a good convention.

Here is the script that creates the secret from the a file https://github.com/simbo1905/laravel-realworld-example-app/blob/master/create-env-secret.sh

So I run that with NAME=xxx ./create-env-secret.sh .env.live to create a secret xxx where xxx should match the name of the deployment. We have an .env.live and .env.staging etc that match the names of our openshift projects that use different databases.

Obviously, you don't want to commit your secrets into Git! So the .gitignore should name the file holding the secret env vars e.g. echo .env.live >> .gitignore ; git add .gitignore.

Finally, we use git secret from git-secret.io to gpg encrypt the secret files so that we can commit to github the encrypted files that will be vision controlled with the code.

[simbo1905]

@J5Dev I documented all the steps to use both laravel and reactjs on openshift at https://gist.github.com/simbo1905/d27ba7218a2fd71fcb4f0fcede82fd6d#build--run-the-realworldio-laravel-backend-demo so you might want to try those out using my version of the code. Note it is using my copy of the demo which is listed at the top of that page not the version at this repo.

[J5Dev]

Thanks for this super useful, more than enough to get me on my way :)

For reference, here's what I am putting together... basically similar to this repo, but based from an Ubuntu image, (I prefer it to CentOs, Im just me :) ), and with Redis, and plan to build a few other things in as well.

My Laravel App: https://github.com/J5Dev/laravel-test-app
My Ubuntu base images: https://github.com/J5Dev/s2i-base-images

[simbo1905]

Our stuff is proprietary code in production on Openshift Online Pro on AWS so we run rhel7 images to get long-term support security patches. In the oc and k8s world the distro shouldn't really make any difference as it allows us to focus on the application and not the incidentals of the environment.

[J5Dev]

Totally with you, and in the same boat going a very similar way, and will most likely end up on the RHEL images... though with IMB not AWS. I'm more using this as a vanilla way to build up the config/templates etc. without exposing any prod code.

After all once I know it will build and run the base Laravel, anything after that is easy to find and quash :)

Thanks for your help though, put me on the right track, I just need to add the secret generation to my build config and have it bind it into the env. Will post the code once done for anyone else finding this :)

[simbo1905]

Cool. Here's a script that scans RedHat long term support s2i image and compares with what you have in your openshift registry and outputs the commands of import new images and apply it to your builds https://github.com/UniqKey/openshiftbot/blob/master/bin/nodejs-8-rhel7.sh Thats the node version about to setup the same for the PHP s2i.

[J5Dev]

Awesome, thanks for the help!

[J5Dev]

Just thought I would leave an update, should anyone else land here...

In order to get this to work still using my template approach, I have had to add an additional parameter which captures the project name as it isn't yet available to just reference within a template, (see here for details).

So what I now have is:

Parameter reference

...
  "parameters": [
    {
      "name": "PROJECT_NAME",
      "displayName": "Project Name",
      "description": "The name of the current project, or project this will be deployed to.",
      "required": true,
      "value": "my-project"
    },
...

And then using this added it to the env declaration in the nginx/php containers deployment config

...
"env": [
  {
     "name": "DB_HOST",
     "value": "${DATABASE_SERVICE_NAME}.${PROJECT_NAME}.svc"
  },
...

This solved my problem.