We are investigating how to integrate our app with Github Enterprise.
There are 2 different deployment models - 'Cloud' and 'On Premise'
I have been looking around but couldn't find the differences between the two.
Maybe there is no such difference
The basic difference is that GitHub Enterprise Server is software you deploy on a virtual machine you provision and control (on-premise here is a bit of a misnomer since your VM could be in AWS).
GitHub Enterprise Cloud, on the other hand, is an enterprise-level of service at GitHub.com.
You'll find more here.
i am really confuse about the main difference between Open Stack and development Stack ?
is it different version or different platform ?
First of all, let's get the terminology correct. You are talking about OpenStack (one word) and DevStack (one word).
OpenStack is a suite of services for managing computing and related resources. You typically use it for managing "cloud computing" resources, consisting of multiple physical compute and storage servers. Setting up a system like this for production use on "real" hardware takes a lot of time and expertise.
DevStack is a essentially a set of scripts that will set up set up a simple OpenStack test environment running as virtual machines on (typically) a Linux PC with a few GB of RAM and a chunk of free disk space. The purpose is to allow a developer to set up a tiny cloud for trying things out, and doing service development work.
OpenStack and DevStack are neither different versions or different platforms. They are different parts of a larger whole. (You could say that DevStack is part of the OpenStack suite of software. Development of OpenStack and DevStack are handled by the same umbrella organization under the same governance, etc, etc.)
I work for a small web startup. They have decided to use OpenStack as IaaS and then on top of it, cloudfoundry as PaaS. I am trying to learn about this technology stack. But I am really confused even after going through documentations and related materials on the web.
What do I want?
I have a web site, that currently runs on a RHEL system (aws instance), with
nginx as web server. I want to shift this to OpenStack-cloudfoundry
stack because the company's management has decided to do so. They also
want me to evaluate if I can put Docker to use anywhere.
From my understanding, OpenStack (Iaas) will provide me with all stuff related to hardware software needs, and cloudfoundry will help me on the development front.
Now, where does nginx (or any web server) come into the picture? Is it part of Openstack or Is it part of cloudfoundry?
On my aws RHEL system, Do I just install Openstack and Cloudfoundry, and then push my app and not at all bother about what happens beneath? I am really confused.. please help out.
And, Is there anywhere I can utilize Docker, in this setup?
You would generally not deploy OpenStack on top of AWS. OpenStack is similar to AWS in that it provides a service for you to create and destroy virtual machine instances, manage networking between and around your VMs, attach and detach block devices to instances, etc. In other words, both are services for managing "infrastructures", where "infrastructure" here means a virtualized datacenter, which at its core means a bunch of hardware running hypervisors that allow you regard the datacenter as a bunch of virtual machines that can be spun up and down on demand, rather than a bunch of "static" physical machines.
AWS is an Infrastructure-as-a-Service provided by Amazon, so you don't have to install AWS yourself, you can just start using it to provision VM instances within Amazon's datacenters. OpenStack is software you install yourself (or pay a vendor to manage for you) on hardware you own or pay for yourself, and once installed OpenStack provides a similar service/interface to AWS.
With a Platform-as-a-Service, you concern yourself more with your application code, and "just pushing it", and don't have to concern yourself as much with what's happening on the underlying machine. You don't have to worry as much about the underlying OS, making sure you have the right runtime and code dependencies of your application, generally don't have to care about the webserver that's serving your code, etc. And you get many more higher level features, e.g. easy ability to scale vertically or horizontally, dynamic routing, automatic log aggregation, automatic health management, etc.
As far as how nginx fits in, it depends how you're using nginx, and what kind of application you have. Cloud Foundry has few couple ways of dealing with applications.
One is the buildpack model, where you simply push your source code to the platform, and it will automatically detect the appropriate runtime and dependencies for your application. For instance, if your application is a Ruby application, it will automatically detect this, and by default automatically run the application using the WEBrick server. However, you can choose other Ruby webservers such as Phusion, Passenger, etc. [1]
If your application is primarily serving static content, it will use nginx as the webserver. [2]
Another is using Docker. You can deploy applications based on Docker images on Cloud Foundry, in which case you could have a container running nginx and your application inside the container, or not, it depends on whether you still need nginx. Pushing a docker application is as simple as:
cf push trainingwebapp --docker-image training/webapp -c 'python app.py'
Here, this uses the sample Hello World web app from the Docker documentation. [3]
[1] https://docs.cloudfoundry.org/buildpacks/ruby/ruby-prod-server.html
[2] https://docs.cloudfoundry.org/buildpacks/staticfile/index.html
[3] https://docs.docker.com/engine/userguide/containers/usingdocker/
I'm developing a meteorjs application and wondering what is better , actually deploying in meteor js cloud is elegant , free , and work perfectly, but is this will still free , is their any limit or compensation .
This question is very obscure by nature and will receive mostly opinionated answers. I have a feeling it will be closed before too long but for archival sake and to answer your question. Meteor's current free deployment has no guarantee of uptime and shuts down the app when not in use until another user attempts to access your app. For demo's and prototyping this should be fine.
However I would highly suggest that if you need something reliable and for use in a production environment stay far away from the current Meteor service for deployment. You are limited to a database size and how much access you have to things such as the file server. There are many great services out there that allow you to deploy just as easily.
Check out modulus.io for super simple deploys. If you are on more of a budget you can choose a service such as Digital Ocean or any other VPS service that allows you to install Ubuntu and use something such as MUP which is a great package made by Arunoda for deploying to Ubuntu based systems.
I want to create a modestly scalable development environment for an in-development web service.
Ideally, there would be an nginx web server with haproxy and a few database servers, websockets, the works.
I'd be going with Amazon cloud services for all of this hosting... but I'd rather not pay for CPU cycles when I'm just developing... much less develop on a remote, cloud environment.
What's the best way to go about modeling a somewhat complex development environment locally that could - hopefully, at the press of a button - sync with a similarly architected Amazon cloud environment?
All I have is my Macbook Pro. I also have a fully built 1Ghz tower computer in the closet I could leverage, if needed, and wouldn't be opposed to buying more. But, ultimately, I'd like to have the ability to sync to production with minimal steps and reconfiguration.
Thanks!
Check out vagrant and virtualbox. That will get you local environments running nicely on your macbook. Syncing to EC2 is going to be tougher. At the system level you'll want to use something like puppet or chef (which are both nicely supported by vagrant). Add to that a solid automated application deployment mechanism and you should be close. Be prepared to put some time into this, it's not likely to be a trivial undertaking.