I want to build my own pass platform based on cloudfoundry and openshift. I want to use some of the functions of these two platforms, and I don't want to deploy them all in the environment. Is this feasible? What similar open source projects can learn from?
Let me produce some contents about OpenShift for you as follows.
OpenShift Online : Free plan is enough to your first training.
OpenShift HandsOn training : Awesome practical training, it need not to prepare your env.
OpenShift Documentation - Enterprise and OpenShift OpenSource AKA OKD - Documentation
If you'd like to deploy to your on-premise as open source project of OpenShift, you can review/test/operate the OKD (former name: OpenShift Origin).
I hope if help you. :^)
In regards to Cloud Foundry, it is just a collection of services. We use Bosh to deploy Cloud Foundry, which knows how to deploy all the services so that they can talk to each other & function cohesively. There's nothing that would prevent you from using a different Bosh configuration (or even totally different tool) to deploy these services in a different way.
You can run projects like Gorouter, UAA, Cloud Controller and Garden stand-alone. The individual project sites typically have instructions for doing this.
Ex:
https://github.com/cloudfoundry/gorouter#start
https://github.com/cloudfoundry/uaa#quick-start
Other components might be a little trickier as they depend on each other. Diego, for example, depends on Garden and is built to send logs through Loggregator. In these cases, you might need to do a little work if you didn't want to use one of the dependent components.
https://github.com/cloudfoundry/diego-design-notes#what-are-all-these-repos-and-what-do-they-do
I would disagree with your comment about these systems being bloated, and say that depends on your perspective. If you don't need a lot of the features, then I could see why you might think that. I'd say overkill might be a better way to put it though.
If you don't need all the functionality that PaaS platforms provide, you could look at other options: Dokku, Kubernetes, Knative, etc... You don't get all the features of CF, but the systems have smaller footprints. If you can live without the extra features, then these might be better options for you.
Hope that helps!
Related
The 3rd factor of "The twelve-factor app", states that the application configuration must be stored in the environment.
For the image of a Quarkus application deployed on OpenShift, what is the best solution: where can I put the application configuration?
Thanks a lot.
Kind regards.
ConfigMaps are designed for this exact purpose. (The opening line of the documentation is "Config maps allow you to decouple configuration artifacts from image content to keep containerized applications portable.") Secrets are the equivalent functionality for sensitive information.
ConfigMaps generally the I recommend for most situations. Because, as you say, this is a universal solution that can be used for all kinds of applications, no matter how they are implemented. Pods have many ways of accessing ConfigMaps , all OpenShift and Kubernetes tools will understand how to work with ConfigMaps (icluding things like CI/CD), and ConfigMaps are native API resources. Because they are so pervasive, many frameworks also have native support for them. Including Quarkus which was your specific example.)
That said, you also ask in your comments about whether you can use Consul. Absolutely you can, Consul is certified on OpenShift. There are LOTS of third party solutions. And there are reasons that people choose to use them.
But if you ask the generic question "How do you do this in OpenShift?" I will point you to ConfigMaps. If you want to use something else (like Consul) then how you access and manage that config really has to be a question for that product. It looks like there is a Quarkus extension for Consul, but I don't know anything about it.
I use Deis Workflow, which is an open source Platform as a Service (PaaS) that makes it easy to deploy and manage applications on our servers.
I understand twelve-factor is the main guideline for Deis Workflow, but is it possible to use it to create services like Postgres, Redis or MySQL?
Some other PaaS services e.g. Dokku and Flynn allow users to create services and link them to the app containers.
Is there a way to acheive the same result in Deis Workflow?
I'm an engineer at Deis, formerly from the Workflow team, and still occasionally involved in it. Great question. As it seems you already caught on to, Workflow is (currently) hyper-focused on 12factor applications. Generally, what we have said is that anyone wishing to do anything more complex than that may wish to "fall back" on "plain Kubernetes," but that doesn't have to be as painful as it might sound when you take Helm into account. Helm is the Kubernetes package manager (and is another Deis product). Helm 2 just went GA today, in fact. It's easy to create your own Helm charts (packages), but even better than that, many charts already exist for common things like Postgres, Redis, and MySQL (all examples you gave). Hope this helps.
I am Anton - one of the maintainers of Hephy, the open source fork of Deis Workflow. https://github.com/teamhephy
Deis Workflow was originally designed with hyper focus on 12-factor apps and deploying them. We don't see any major changes to that in the coming few months except the possibility to define multiple services per application namespaces. See this PR: https://github.com/teamhephy/controller/pull/71
Aside from all of this, we hope to integrate other services that provide DBaaS (Databases as a Service) and do some blog posts on how to use Hephy Workflow and those services together for a common solution.
I have a generic question here and I have just started using Openshift enterprise and Origin but I would like to know the details on Cloudforms UI, I know that CloudForms UI can do a lot of things including managing Openshift instances but I would like to know the following in terms of managing Openshift instance, can CloudForms be able to do the following :
Order New Openshift environments[For ex, DEV, UAT and PROD], where I could say how many nodes and other details I need for those environments?
Could I be able to plug-in custom tools like ELK/Splunk or AppDynamics to the ordered environments as part of provisioning or later?
Could I be able to populate locally build images and publish it to all the users for using them? For ex: Suppose my middleware teams build images for Tomcat, Nginx etc and they could be able to publish it in CloudForm and I could be able to add them to my newly ordered environments through the Cloudforms UI, could this be done?
Could I add multiple registries and integrate them with my ordered environments.
Does it have all the features that Openshift Enterprise console has? like scanling, S2i etc.
Could I promote my images from one environment to other through the Cloudforms UI?
Can I integrate CI/CD tools and build environments with my ordered environments?
The RBAC in CloudForms can it be modified and catered to suit my requirements/ could this be customized to suit any firms needs?
Could I replicate my DEV openshift ENV to UAT and then to PROD environments? I did see replicators tab in the videos.
Can a charge back model be implemented in the Cloudforms UI ? if its already there then could be customized?
What I am trying to find here is to see if CloudForms can provide an end to end Openshift solution. The end user must only have his/her code ready, rest everything could be within the UI.
Kindly let me know what all are possible and what all are not.
CloudForms is not trying to substitute OpenShift UI, but complement it, giving you more information about the environment and providing additional capabilities on top of OPenShift.
You can see information about what is being done and demos in videos:
https://www.youtube.com/watch?v=FVLo9Nc_10E&list=PLQAAGwo9CYO-4tQsnC6oWgzhPNOykOOMd&index=15
And you can find the presentations here
http://www.slideshare.net/ManageIQ/presentations
Time and again I am faced with the issue of having multiple environments that must be configured individually for an application that would run in all of them (e.g. QA, regional production env's, dev, staging, etc.) and I am wondering what would be the best way to organize different configurations?
Would it be in the database? Different configuration files per environment? Or maybe the same file with different sections/xml tags? How would these be then deployed? Embedded within the app? Or put manually in after installation to be modified in-place?
This question is not technology-specific - I've worked with .net and Java, web-apps and desktop apps and this issue comes up time and again. I'm looking to learn different approaches to maybe adapt a hybrid to address this.
EDIT: There's one caveat that I must point out - when configuration is part of the deployed solution, it is generally installed under root user on the host. In large organizations developers usually don't have a root access to production hosts so any changes to the configuration require a new build and deployment. Needless to say this isn't the nicest approach - especially at organizations that have a very strict release process involving multiple teams and approval levels... (sigh I know!)
Borrowed from Jez Humble and David Farley's book "Continuous Delivery (page 41)", you can:
Your build scripts can pull configuration in and incorporate it into your binaries at build time.
Your packaging software can inject configuration at packaging time, such as when creating assemblies, ears, or gems.
Your deployment scripts or installers can fetch the necessary information or ask the user for it and pass it to your application at
deployment time as part of the installation process.
Your application itself can fetch configuration at startup time or run time.
It is considered bad practice by them to inject configuration files in build and compile times, because you should be able to deploy the same binary file to every environments.
My experience was that you could bake all configuration files for every environments (except sensitive information) to your deployment file (war, jar, zip, etc). And you design your application to take in an extra parameter when starts, to pickup the right sets of configuration files (from your extracted deployment file, or from local/remote file system if they are sensitive, or from a database) during application's startup time.
The question is difficult to answer because it's somewhat vague. There is no technology-agnostic approach to configuration as far as I know. Exactly how configuration is set up will depend on the language/technology in question.
I'm not familiar with .net but with java a popular approach is to have a maven build set up with different profiles. Each profile is specific to an environment. You can then define different properties files that have environment-specific values, an example from the above link is:
environment.properties - This is the default configuration and will be packaged in the artifact by default.
environment.test.properties - This is the variant for the test environment.
environment.prod.properties - This is basically the same as the test variant and will be used in the production environment.
You can then build your project as follows:
mvn -Pprod package
I have good news and bad news.
The good news is that Config4* (of which I am the maintainer) neatly addresses this issue with its support for adaptive configuration. Basically, this is the ability for a configuration file to adapt itself to the environment (including hostname, username, environment variables, and command-line options) in which it is running. Read Chapter 2 of the "Getting Started" manual for details. Don't worry: it is a short chapter.
The bad news is that, currently, Config4* implementations exist only for C++ and Java, so your .Net applications are out of luck. And even with C++ and Java applications, it won't make pragmatic sense to retrofit Config4* into an existing application. Because of this, I'd advise trying to use Config4* only in new applications.
Despite the bad news, I think it is worth your while to read the above-mentioned chapter of the Config4* documentation, because doing so may provide you with ideas that you can adapt to fit your needs.
We use Incredibuild here to compile our code in a distributed fashion. I was wondering if there are any open source (or free) alternatives to use on a home network?
Failing that, are there any other simple solutions with good integration with Visual Studio out there?
EDIT: I should say that I am quite happy to get my hands dirty and manually configure everything on each machine should that be required.
I can't look past TeamCity as a CI environment - among other features it allows multiple build agents to be linked together in one build grid.
Oh and it also has excellent integration with VS and SubVersion. And it's free to use, up to a maximum of 20 build configurations and 2 build agents.