After evaluating existent tools like Ansible Tower, rundeck and others, it seems that no tool can fulfill the needed requirements.
We have complex data-center servers, cluster of DB and web servers, the data-center has a lot of client-systems, +100, and other tools like solr, redis, kafka... deployed there across the physical servers, not to mention that the same data-center servers have different accounts, linux users, (QA,stag,production..etc), for now the meta-data about these environments alongside their web-apps, source code to be used, servers of the cluster are all defined on xml and there is a bash scriptsreads from that XML that operated manually to run any operation/task (like checkout the source, build, deploy, start, stop... and other customized operations)
This system should be done with a developer and DevOps engineers together, but what I want to know, is there any preferable framework(s) that could be used for this system? does the workflows frameworks are usable on this case? e.g, Activiti BPMN? the Ant is an option but we don't need just an automation tool more that scheduler and logging and a lot of other services.
And if this is not the right place, can you please point out where cat I ask such question?
What's required is to create a web-based system as automation tool with:
UI to define the specific operations to be done, like build, deploy across the cluster specific web-app on specific env, start/stop specific web-app on specific machine, or any other customized operation, with multiple selections and flexible and dynamic options choosing way.
The FE should show the executing workflows and operations within them.
Dynamic way to create set of operations as a single workflow, that have dynamic ability to set the dependencies among them.
An interface between the back-end code of this system with the already existent bash scripts that will do the actual tasks across the DC servers.
A scheduler to be able to organize these operations in respect to a defined complicated dependencies between the workflows.
Authentication & authorization services to the users since there will be a lot of customized roles upon the operations,environments, the products...etc
Logging system to save the operations outputs.
Why not use a combination of ansible/Docker and jenkins, Jenkins can do most of the stuff you described using Pipeline projects/MultiProjects and Ansible for your UI and role related details
The task you're describing is basic network orchestration, and there're a bunch of orchestration engines/software out there. However, the fact that you are asking this question means you're just starting out and not ready to invest in a full fledged management product yet.
I strongly suggest that you take a look at Chef for your purposes.
Hope this helps.
I would recommend you to take a look at jenkinsx.io if you are targeting kubernetes and containers (docker). As part of the activiti bpm team we are trying to align with such technologies to make people life easy to integrate more complex workflows with DevOps and operations of your projects.
Related
I am currently working for an enterprise and have been asked to use GitHub Actions instead of ADO/Azure Pipelines or Jenkins.
My objective is to create a self-service model where we have a basic CI/CD framework that teams can use as a starting place for their pipelines. It has all the security, quality, and governance rolled in, making life easier for devs and reducing duplication of effort. Thus reusable workflows are a must, and being able to launch containers from a build agent/runner/worker is a must.
Let me lay out my understanding of the situation with GitHub Actions:
Github Actions can do two things:
Launch a Container
Run JavaScript
Running a container within a container is a considered a bad idea, and in fact, support for it is going away in the near future.
GitHub Hosted Runners run in a container.
Github Actions don't support Reusable Workflows until Q3 of 2021
If my understanding is correct, then I'm dead in the water:
A GitHub hosted runner for Actions is basically useless in my case unless I want to write JavaScript.
It looks like I'm back in the VM business to self-host a runner so that I can use it to host containers instead of running Docker within Docker
My ability to create a generalized framework for my dev teams is somewhat undermined until GitHub gets around to implementing Reusable Workflows. (I think this is the biggest assumption, most likely to be disproved with a workaround)
Before I push back for a different CI tool, somebody please tell me what I'm missing here or what workarounds make this do-able.
After additional research and some testing, my hypotheses were confirmed:
Using a self-hosted runner on a VM is the most straightforward way to solve the "container-in-a-container" problem. It also solves the problem of consuming private/self-hosted package feeds from the runner without whitelisting every i.p. range used by GitHub hosted runners, which something most enterprise InfoSec teams would be reluctant to do.
This question had second one rolled in, "How to create a reusable CI/CD framework for an enterprise in GitHub Actions" which was bad form on my part. The most straightforward options are a) wait until Reusable Workflows are fully implemented and worked out b) use a more mature orchestration tool like Jenkins, TeamCity, or Azure DevOps if you can't wait.
A couple of things to look at:
You might be able to use create your own GitHub actions to share behavior, info on how to call here.
For self hosted then docker-github-actions-runner is a great starting point.
We are planning to implement jenkins for the whole organization. We want to go with single jenkins instance that will be used by many teams with Slave architecture. I want to know if there are any best practices for Plugin management. Since teams would request for installing different plugin, how can i manage these plugsin installation.
Thanks in advance for all your help
I would install Docker on all agent machines and instruct teams to make use of Docker containers in their Pipelines as much as possible. Thereby you forego the need of installing different programming languages and plugins on all your agents.
For plugins that really have to be added to Jenkins, I'd set up a test instance of your Jenkins server, to try out the plugin, and see whether it clashes with existing plugins. Try to keep the number of plugins low, suggest people to only use quality plugins that get recent upgrades, and remove plugins when you no longer need them.
One issue you will encounter is Jenkins has no (as far as I can find) authorization strategy for plugins. Basically, all plugins are available to everyone. Thia may be an issue if teams have different and contraindicated requirements (eg: a team not allowed to use ssh or HTTP requests). If you have a homogeneous approach to SW development, code, infra, tools, etc, then it becomes a matter of scale only..
In a large org, you also may have issues with a single Jenkins merely finding maintenance windows. It also creates a single point of failure.Are you OK w/that or need H/A?
You may benfit from several masters (per business unit or product) and use JCasC to manage common configurations overview, plugin to make your life easier.
I could not find the difference between these two. Are these same or different.
The first difference is support (as others have mentioned). CloudBees offers enterprise grade support as well as a fully vetted and tested version of Jenkins that will be more stable under various plugins and deployments. You can actually purchase "Support Only" from CloudBees if you are satisfied with your OSS Jenkins deployment and simply want support during upgrades, patching, break/fix, etc.
From a feature perspective, CloudBees brings a lot from an enterprise manageability, scalability, and security standpoint.
Manageability: CloudBees comes with CJOC (CloudBees Jenkins Operations Center) built into the software. This is a single pane of glass management console that allows organizations or large teams to centrally manage the jenkins environment. Things like folders, RBAC, pipeline and master templates, and the ability to rapidly spin up/tear down a containerized jenkins master are all managed from this single console.
Scaleability: CloudBees leverages Kubernetes to provide organizations with the ability to elastically scale Jenkins environments as needed. With CloudBees, your oganization can move away from a single "Monolithic"/"Frankenstein" master and into a multi-master and distributed pipeline architecture. This greatly reduces upgrade and administration complexity. This also eliminates the risk from a single point of failure that a monolithic architecture exposes.
Security: CloudBees allows organizations to install Roll Based Access Control within Jenkins. This keeps users from accidentally or intentionally accessing repos that they shouldn't be allowed to interact with. CloudBees also provides "folders" to segregate specific job executions onto specific agents. Lastly CloudBees allows organizations to create pipeline templates and associated plugins for each team. These templates can be as rigid or loose as desired per the organizations security policies.
CloudBees is regularly adding enhancements to further differentiate themselves from Jenkins Open Source and make themselves more appealing to large enterprise requirements.
On top of the above, CloudBees has developed a presentation layer that rides on top of Jenkins for SDLC pipeline, CD monitoring, and metric tracking called DevOptics.
Jenkins is open source while CloudBees Jenkins Enterprise is a commercial extension of open source Jenkins. Go here for an up to date comparison table.
I am looking for a comparison between IBM Build Forge (Rational) and Hudson CI.
At work we have full licenses for BuildForge but recently we started using Hudson for doing continuous integration and automating other tasks.
I used BuildForge very little and I would like to see if there are any special advantages of BuildForge over Hudson.
Also it would be very helpful to see a list of specific advantages of Hudson over BuildForge.
I not sure if it important or not, but I found interesting that Build Forge is not listed under continuous integration tools at wikipedia.
Thanks for bringing attention to the fact it was not on the wikipedia list of continuous integration applications. I have now added it. Build Forge has been a leader in providing continuous integration capabilities by use of it's SCM adapters for many, many years. Build Forge has a strength in supporting many platforms through its use of agents. These agents can run on Windows, Linux, AIX, Solaris, System Z, and many more -- they even give you the source code for the agents for free so you can compile it on just about any platform. The interface allows you to easily automate tasks that run sequentially or in parallel on one or multiple boxes. Selectors allow you to select a specific build server by host name or by criteria such as "any windows machine with 2gb of ram" from a pool of available agents. The entire process is fully auditable, utilizes role based permissions, and is stored in a central enterprise database such as DB2, Oracle, SQL Server, and others.
One of the most compelling reasons to use Build Forge is it's Rational Automation Framework for WebSphere. It allows a full integration into WebSphere environments to automate deployments and configurations of WebSphere through out of the box libraries. The full installation, patching, deployment of apps, and configuration of WAS and Portal can be performed using these libraries. To find out more, it is best to contact your IBM Rational representative.
You can use RAFW (IBM Rational Automation Framework for WebSphere) with BuildForge. It does not make sense to use RAFW with other ci servers, since RAFW requires BuildForge.
You have support for BuildForge and it integrates with other IBM software like ClearCase. Theoretically you have only to deal with one vendor if something in the chain does not work, but IBM has different support teams for their products and you might become their ping pong ball. :(
Hudson is open source (if you like that), that means you can get the source and modify it to serve you better. But the release cycle is very short (about 1 week, agile development). There is a more stable version with support available now (for cash of course) from the company of the main author of Hudson.
Hudson is currently main stream and is actively developed. I don't know how the usability of BuildForge is, but Hudson is good (not always perfect). The plugin concept of Hudson is a great plus, not sure if BuildForge has it as well.
Currently, we are using Hudson, but BuildForge was not looked at in detail.
You need to define what you would need continuous integration for (e.g. building, testing). Having used Hudson, I can vouch for its usefulness and effectiveness. There are many plugins that extend Hudson that can suit various needs. And you can't beat the price point (free).
You need to inquire as to why a BuildForge license was obtained at your place of employment. Perhaps someone on your team knows why this was done. If it isn't necessary for your needs, don't renew your BuildForge license and simply continue using Hudson.
Being a BuildForge/RAFW user, I have to object to one point stated above. It is perfectly possible to use RAFW without BuildForge. It is driven by a command line script, and you could use for example Hudson and RAFW together just fine.
A sample command would look like:
rafw.sh -e env -c cell -t was_common_configure_start_dmgr
The primary differentiators IMO:
Hudson/Jenkins is more readily extensible with the many existing plugins. It has a large active community and plenty information and documentation.
BuildForge can be configured with agents running on multiple machines and tasks can be assigned to run on a target agent. Reliable vendor support.
FastCGI is old but it still seems like it must be the right answer in some cases.
It seems like the preferred deployment of Perl/Catalyst web applications is with FastCGI.
FastCGI was popular with Rails but seems to no longer be. (Why?)
The Java world doesn't seem to have anything to do with FastCGI. Is something like Tomcat way better than Apache+FastCGI?
Is choosing FastCGI still a good idea or just a lingering technology?
Ted
Since it depends a lot on your setup and requirements, I'll let the "Is X still a right answer?" up to you. However, by looking at different architectures, you can come up with a list of questions to ask to determine if it still is a right answer given specific circumstances.
Concerns of frequent interest
The questions you'll want to ask are usually related to security and flexibility. For security, you'll want to follow the principle of least privilege. For flexibility, you'll want to know if you can run multiple frameworks, multiple versions of the framework and how easily you can delegate work to other tasks.
Other concerns
For a simple web front-end to a database-backed application, not all of these questions are important. You also need to keep in mind that some of the recommendations have nothing to do with what's outlined here. Many web frameworks will recommend whatever architecture is easiest to setup with their framework. They do this because it helps get new users trying out the framework with minimal fuss and without flooding the mailing list. Also, the Java community tends to stick to a common denominator rather than take full advantage of the platform at hand, so they'll often recommend an all-Java solution.
Popular architectures
Single process architectures
From a pure performance point of view, a single process (probably threaded) with an embedded framework probably gives most performance as it reduces most communication overhead between whatever receives the request and whatever produces a response.
Security: a single process must have all of the permissions required to perform every single task it is handed. In simple applications, this might not be a problem. However, its possible you might serve multiple services
Flexibility: probably can't run multiple version of the same framework (e.g. code for different parts of your website require different versions of Java, Rails, Python, etc.). Moreover, changing your setup to serve some work on different machines becomes painful (less difficult when split up on virtual hosts).
Sub-process based architectures
Under the CGI model, you have to pay the price of spawning a new process for each request. Even on UNIX machines where spawning a process is considered cheap, 600 requests a second will kill your server if you spawn a process for each.
Security: to spawn child processes under different user accounts, your gateway probably runs under quite high privileges.
Flexibility: additional flexibility for the multiple frameworks, multiple versions, multiple languages approach, but you're still stuck on the same machine.
Distributed architectures
The FastCGI/SCGI approach tried to solve the CGI process management problem in a clean way. Just keep the process alive. Have the gateway talk to that process to serve the request.
Security: Because the gateway doesn't spawn the processes that serve requests, the gateway can run with far less privileges enabled. Actually, if it only serves as a gateway and doesn't do any work itself, it can run with hardly any privileges at all.
Flexibility: you get even better flexibility than the CGI model because you can forward the request to any machine on the network.
Conclusion
I like FastCGI, because it gives me high flexibility at a price (i.e. request forwarded through socket) I can afford to pay. It's not my full time job to administer systems. I don't develop all the apps I hosts. This means I look for the easiest solution for hosting whatever I try to host. FastCGI popular enough to be supported by major web servers and popular web frameworks. Adding another app usually just boils down to installing and mapping the desired URL to the application over FastCGI.