We run a 'traditional' virtual infrastructure (KVM and VMware) and company policy is to not use containers in production environments. We require an installation method that installs Ansible AWX directly on a host as a web application that does not involve downloading or building a container image.
It is also preferred that the database (if there is one) is installed or created on a separate host.
We have sound business reasons for this, and this is not a forum to challenge our policies.
It would be acceptable if this process was an Ansible play.
Search for installation method that does not use container technologies.
Expect there to be documentation for non-container based installations.
No documentation found, not even googling.
N/A
Sorry, it's just not something we have planned at the moment.
You might consider checking out Ansible Tower, which is the downstream of this project especially given this:
We have sound business reasons for this, and this is not a forum to challenge our policies.
So, no manual installation process of the application will be given, only pre-packaged black box containers?
@Aethylred That is correct. The containers are the only installer for the AWX project. Ansible Tower has an installer that works with traditional virtual infrastructure in the way you describe, but AWX does not.
@matburt @ghjm lacking a manual install process also makes it hard to audit/monitor if the containers are doing (and are _only_ doing) the 'things' required to make AWX run.
Thanks for your answers by the way, just because I don't like them, doesn't mean they're not valuable.
I have done the manual install for Tower with a trial licence, however that was too limited for proper evaluation. We were wanting to do a pilot with AWX and use it to build the case for Tower, while complying with the no-container policy etc. 🤷♂️
@Aethylred If you are looking for a standalone install just to build a case for tower you could look at this:
https://github.com/MrMEEE/awx-build/blob/master/installguide
This isn't a supported way of building but if it is only for POC I don't see that being an issue
@Aethylred We can surely get you a larger Tower evaluation license. Drop me an email (email address is on my profile) and I'll put you in touch with the right people.
@ghjm as someone who has a tower license already; i'd also like to see AWX opened up for install without containerization. It seems, based upon this thread at least, my fears about AWX were not unfounded. I realize your company needs to make a profit, of course, we all do. But, if you're going to use AWX as a marketing tool to push tower on people; can you at least be a little more forthcoming about that? I've wasted a lot of man hours trying to get these things to work in an effort to save man hours on a few use cases. It looks like it was all for naught.
AWX is absolutely not a marketing tool for Tower any more than Rawhide is a marketing tool for Red Hat Enterprise Linux... it's just the upstream development repository.
While AWX may not be a marketing tool, without any way to install it anywhere other than in a container, I also don't see it becoming a widely used platform, which I suppose is by design.
+1. Having this only available as a container install is not useful to us.
+1 Agree that having this only available as a container install is not useful to us.
+1 Agree that having this only available as a container install is not useful to us.
+1 Agree that having this only available as a container install is not useful to us.
+1 For removing container only installation method.
Your guidelines regarding support clearly indemnify you of dealing with all the support requests that will surely follow if you open awx up to installation outside of containers. The opposite consideration would be for allowing slightly more customization prior to running the installation script. Any thoughts on that?
@ghjm wrote:
The containers are the only installer for the AWX project. Ansible Tower has an installer that works with traditional virtual infrastructure in the way you describe, but AWX does not.
I just leave that here: RedHat: Open Source or Open Core: Why Should You Care?
There are several true open source software providers helping to not only drive this innovation, but working to make open source mission critical and consumable by enterprise customers, Red Hat included.
The open core development model, where vendors open only portions of their software and then surround the remainder with proprietary-by-vendor offerings, simply does not work. It is a narrowly-cast version of open source that only stands as a matter of corporate convenience for technology providers who continue to hold on to antiquated proprietary offerings, delivering minimal innovation.
;)
This whole thing stinks. If Red Hat wants to help me make decisions about how and when I use open-source software then I can choose not to use Red Hat products. Thank you for all the work you've done in the FOSS community, but frankly you've lost your way.
WORD - and yes you can ;) That's why we use alternatives (like Debian, Ansible project & co) ourselves and actively help in the FOSS community (developing & support).
But enterprise customers still want that "RedHat stuff", so we're bound to "it". I'm not a big fan of RH lately, because it's always about the money, while the quality of the products sometimes getting worse. However, I do appreciate what they've did in the past for the FOSS community and that they've open-source'd the Tower recently.
Now it's upon us if we 1) want to use the product and/or 2) support & enhance it - as part of the FOSS community. If someone doesn't like the product, then fine, just walk away and everybody's happy. Unfortunately, you often see it in the FOSS community, that companies or individuals get bashed when a product isn't working flawlessly. That's not really fair, especially for something you get for free and where people or companies spent a lot of time and hard work in it.
However, IMHO the problem here is:
1) RedHat is selling itself as "open source leader" of the world
2) They've a feature in their "enterprise" version, which they apparently won't open-source in the upstream project
3) At the same time they're trying to sell licenses for the paid enterprise product on GitHub
So the verdict here is: The "open-source leader" is trying to _force_ you NOT TO USE open-source :)
TBH, that's not very clever and not very FOSS-friendly. FOSS is FOSS and there shouldn't be people trying to sell you an (expensive) enterprise feature in the issue tracker of GitHub. I'm quite sure if RH would've open-sourced the whole tower and their codebase, both parties (FOSS and RH) would win in the long term. Hopefully that will happen one day :)
Thanks to you all for your support.
We're operating physical infrastructure with OpenStack & KVM hypervisors. We have no-cloud and no-container policies. We're OK reading Ansible plays though.
@ghjm we expected the FOSS/commercial product to be the same model as FreeIPA/RHIdM or Spacewalk/Satellite allowing us to do a FOSS install in our test environments for evaluation (and test & dev). Evaluation requires an install as if it was the purchased product. We'd also expect the evaluation period to last a number of months, to operate at the same scale as production, and to include a number of version upgrades.
Also: We're using FreeIPA, getting kerberos keytabs etc into docker containers is less than fun.
have no docker related infrastructure here. and no need to even use it.
+1 Agree that having this only available as a container install is not useful to us.
+1 Agree that having this only available as a container install is not useful. I would go so far as to say it impairs my adoption of AWX/Tower.
Or, baring that, more documentation around install. Initially had issues with docker not using proxy (in October). This is solved now, but now I have issues setting up the postgresql container. Edit: I was wrong, current issue is still proxy, I needed to set /etc/systemd/system/docker.service.d/http-proxy.conf and /etc/systemd/system/docker.service.d/https-proxy.conf
Edit 2: maybe I was a little dramatic, now that it's working for me it's quite helpful and I haven't had to touch the containers... except to set up HTTPS.
@Aethylred We're happy to provide you a fully-featured eval license to Tower. AWX is upstream, and not really the thing you'd want to use to eval whether or not you'd want to potentially use Tower. It's great that you're interested in Tower, and we'd love to help you eval it by sending you a license. Just email us at [email protected], and we can send you one.
@justnems as I said before:
we expected the FOSS/commercial product to be the same model as FreeIPA/RHIdM or Spacewalk/Satellite allowing us to do a FOSS install in our test environments for evaluation (and test & dev). Evaluation requires an install as if it was the purchased product. We'd also expect the evaluation period to last a number of months, to operate at the same scale as production, and to include a number of version upgrades.
This is not a Tower issue that can be resolved with an offer of a trial Tower license. This is an issue with AWX in that it can not be deployed outside of the restrictive docker developer environment.
I don't see why this issue is being rebuffed by the project. You have to build a container anyway. a container is nothing more then a pre-packaged operating system structure (Give or take minor differences). Since Ansible its self is supposed to do deployments shouldn't this project embrace the idea regardless where you install it (bare metal, VM's , containers, ... ) the same install and compile process is used?
While I see both sides of this discussion, I am also a fan of non-container installs. Its silly to make containers when you on virtual systems already and it is only running that one application. I might get the reason if we were dealing with obscure binary libraries or non-orthodox installs. But we are not.
Let me write the installation documentation for the project!
Requiring a party to adopt docker or any specific virtualization or container technology to use, participate, or contribute to a project is not reasonable. As a consequence, you are limiting its adoption and your audience.
I am volunteering to author the non-docker installation documentation but I do need access to a project member to provide requirements, answer questions, and review the draft for accuracy.
Examples of my documentation can be found here at https://github.com/rharmonson/richtech/wiki.
That really sucks.
Agreed.
As the implementer of AWX our organisation I would like the flexibility of having the database on our postgres cluster. Configuring this to sit behind a reverse proxy. Scaling out components of the AWX to different servers. Believe me i do like the docker concept for this install and works for most but we need more install options and flexibility.
I recall seeing somewhere that RH permits forking AWX.
Would there be enough interest to fork it, change branding (required as per RH), and change only to non-containerized deployment?
Edit: I have not looked at the repository, but I presume if only the deployment model is changed (install everything in a single machine without containers) it might not be that big of a task to keep tracking the AWX repository as new versions come out?
Edit 2: It has already been done - https://github.com/MrMEEE/awx-build/blob/master/installguide.md
Aren't there already non-containerized editions available? See https://github.com/MrMEEE/awx-build and https://github.com/subuk/awx-rpm
On Fri, 5/3/19, bluikko notifications@github.com wrote:
Subject: Re: [ansible/awx] Installation without containerisation (no docker, no openshift, no kubernetes) (#989)
To: "ansible/awx" awx@noreply.github.com
Cc: "dyioulos" dyioulos@yahoo.com, "Comment" comment@noreply.github.com
Date: Friday, May 3, 2019, 5:51 AM
I recall seeing somewhere that RH
permits forking AWX.
Would there be enough interest to fork it, change branding
(required as per RH), and change only to non-containerized
deployment?
—
You are receiving this because you commented.
Reply to this email directly, view
it on GitHub, or mute
the thread.
For me it forces also many additional effort to test AWX because it is only available as a container install but additionally it is unacceptable that a Red Hat driven project is not installable if podman and podman-docker is installed instead docker on a CentOS 7.6. I have installed python-docker-py instead the docker module via PIP because according Google search exists only a separate podman module only for python3 and it looks so that there exists no podman-docker shell for Python as for the command line. Docker.py should be able to work with both but maybe not complete because the playbook ends with this error:
TASK [local_docker : Start the containers] ************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Error connecting: Error while fetching server API version: ('Connection aborted.', error(2, 'No such file or directory'))"}
to retry, use: --limit @/home/…
So if you are not able - or amenable 😉 – to offer a container less install so please offer the possibility to use podman (the replacement for docker on newest Federa, on Red Hat 8, future SuSE and more and more).
TIA,
ET
I also do not understand why is there no way to install this on bare metal or VM. There is no benefit.
It has been more than ten months since I offered to write the documentation, but no one from this project has told me to buzz off much less offered themselves as a resource to author an installation document. A completely different experience than the FreeIPA project.
Shout out to Florence Blanc-Renaud and Fraser Tweedale of FreeIPA!
Again, I am offering to author and maintain non-docker installation instructions, but you've got to throw me a bone.
Ansible can run on non-Linux host. If AWX can be installed only as Docker container it means we cannot run it on different OSes where we are running Ansible. It's very sad. Not everybody is running on Linux.
It has been more than ten months since I offered to write the documentation, but no one from this project has told me to buzz off much less offered themselves as a resource to author an installation document.
...
Again, I am offering to author and maintain non-docker installation instructions, but you've got to throw me a bone.
@rharmonson, If they don't care enough, why not to create a repo for yourself? And later open it to collective changes (via PR)? At least we'd have unofficial documentation on "how to use AWX w/out Docker". It's better than nothing.
@rharmonson, If they don't care enough, why not to create a repo for yourself? And later open it to collective changes (via PR)? At least we'd have unofficial documentation on "how to use AWX w/out Docker". It's better than nothing.
Valid suggestion and I have considered it.
It has been a year and four days since I offered to write the documentation. I wonder if folks have lost interest?
Hello, @rharmonson I think there is no more need, someone is packaging it for RPM, I'll try soon https://awx.wiki/ I feel like there is no need for containers for AWX, for me it is simple enough to deploy and maintain bare metal.
@rharmonson I really would like to see documentation for AWX without Docker or RPM to install and maintain it on non-Linux platforms. Please let me know if you write something. I will test it on our FreeBSD machines.
everybody here who wants to help documenting "awx without containers", please go to https://github.com/MrMEEE/awx-build and offer your help there ;)
Most helpful comment
@ghjm as someone who has a tower license already; i'd also like to see AWX opened up for install without containerization. It seems, based upon this thread at least, my fears about AWX were not unfounded. I realize your company needs to make a profit, of course, we all do. But, if you're going to use AWX as a marketing tool to push tower on people; can you at least be a little more forthcoming about that? I've wasted a lot of man hours trying to get these things to work in an effort to save man hours on a few use cases. It looks like it was all for naught.