Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

[WIP] Feature/install script #18

Closed
9 of 12 tasks
licarth opened this issue Aug 20, 2018 · 4 comments
Closed
9 of 12 tasks

[WIP] Feature/install script #18

licarth opened this issue Aug 20, 2018 · 4 comments
Assignees
Labels
feature infra Infrastructure related

Comments

@licarth
Copy link
Contributor

licarth commented Aug 20, 2018

From @licarth on May 4, 2018 12:12

Please don't merge this before #3.

Single line script to run Opla locally with docker and docker-compose.

  • checks currently available versions of docker docker-compose.
  • installs docker and docker-compose if missing.
  • builds and runs opla back and front.
  • opens browser at the end with opla front.

Todo

  • download and extract bundle
  • run docker-compose up
  • adapt travis tests.
  • make ENV variables configurable through prompts.
  • check currently installed versions. Warn and exit if too old. Need docker-compose yaml v2 support.
  • add OSX travis job and adapt script to make it green (fix mktemp and potential other issues) Won't do
  • add linux without docker and docker-compose job to test their installation by script
  • make Yes default answer to questions
  • open opla front in browser at the end of install

Manual testing

  • @mikbry Test on Mac that temp dir works fine
  • @mikbry Test on Mac that opla runs fine
  • @mikbry Test on Mac that it opens browser

Enhancements

  • Add error handling/reporting via HTTP calls, like done in https://install.sandstorm.io/, to get statistics about who installs opla, and the success/error rate.

Copied from original issue: Opla/community-edition/pull/4

@licarth
Copy link
Contributor Author

licarth commented Aug 20, 2018

Changing that to WIP again, I suggest:

  • to add a mac OS job to the test stage with os: osx travis feature (https://docs.travis-ci.com/user/reference/osx/#Using-OS-X).
  • to add a linux job to the test phase where neither of docker or docker-compose are installed. We may need to uninstall/remove them from the path in an install travis phase because they are there by default.

@licarth
Copy link
Contributor Author

licarth commented Aug 20, 2018

Thinking about this, I think one use case is problematic : The "noob macOS user" that does not know what docker is, but wants to try the app. I believe that, for this kind of users, we could come up with a "deploy to the cloud" button that would deploy Heroku (or similar) dyno serving front and backend. Why ?

  1. If we opt for Docker for Mac, the problem is ne necessity of a GUI installation. See here for details. Testing this through CI/CD seems super difficult if not impossible (see here)
  2. If we opt for the old Docker Toolbox solution (available through brew), it seems like a bit or an overhead to me to install VirtualBox on a noob's machine. He may be a noob but will really wonder why his machine is slow all of a sudden...
  3. If we opt for the old Docker Toolbox solution (available through brew), it seems like a bit or an overhead to me to install VirtualBox on a noob's machine. He may be a noob but will really wonder why his machine is slow all of a sudden. Not too good for our image, I believe.

In a nutshell, I believe that it's best to give our users a choice, depending on how familiar they are different technologies :

  • You have docker already ? Cool, use our single line tool to run Opla, or directly our docker-compose yaml.
  • You don't know what docker is ? or do not want to install it on your machine, but you have node ? Cool, run backend and front natively, again with our single line tool.
  • You do not want anything to be installed on your machine ? Fine, the tool will deploy your demo to Heroku (docker or nodejs - based, but user won't see the difference).
  • You don't like Heroku, you have your own Kubernetes cluster on AWS or GCP ? Fine, use our Kubernetes charts to deploy your community edition.

The idea of a single line tool is good, but if they are not developers, I believe that a Heroku deploy button
is enough, to get an idea of how it works. Something in the middle (i.e. installing things on their local machine that they do not understand, I believe, is not a good idea, and can't think of any other app that does that -- including Wordpress).

Now, the production deployments are another story, but they'll happen in the cloud, where docker is provded.

Side note, I think it's a good idea for the tool to be able to uninstall what it has installed as well.

@mikbry WDYT

@licarth
Copy link
Contributor Author

licarth commented Aug 20, 2018

From @mikbry on May 7, 2018 17:3

Ok the install script is here to check that docker compose is up and running and not too old. On Linux it could install Docker. On MacOS, it will display the link to install Docker.

Deploy button is the next TODO, and we will use our solution ;-)

@licarth licarth mentioned this issue Aug 20, 2018
2 tasks
@licarth licarth added feature infra Infrastructure related labels Aug 21, 2018
@licarth licarth self-assigned this Aug 21, 2018
@licarth
Copy link
Contributor Author

licarth commented Dec 6, 2018

It has been merged already.

@licarth licarth closed this as completed Dec 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature infra Infrastructure related
Projects
None yet
Development

No branches or pull requests

1 participant