how can we download ( not install - at least for now) all files for ansible to a zip ?
and then - later on ( not immediately) use this downloaded archive to install ansible to create new or existing ansible or non ansible host ( Why they want to do zip/gz vs installing via "sudo pip Install ansible " I do not know - please don’t ask since I don’t know “why must zip or gz it” ).
can we after installing it simply zip up pristene ansible installation from what was installed on Ubuntu ? and later unzip this to a new host in order to get ansible working on new host ?
Mind you: you probably don't want zip when there is already a
published gzipped tarball. And, frankly, you probably don't really
want the "ansible" package. You probably really want the
"ansible-core" package, which was split in a very confusing fashion
from the mountain of ansible_collections modules that are published as
the "ansible" tarball, but is of no use without ansible-core.
ansible-core gets you the tools to pull down the "collections" modules
only if and as needed, and that can save you hundreds of Megabytes of
local space filled with bulky modules you don't use on your ansible
server.
Nico Kadel-Garcia
and then - later on ( not immediately) use this downloaded archive to install ansible to create new or existing ansible or non ansible host ( Why they want to do zip/gz vs installing via "sudo pip Install ansible " I do not know - please don't ask since I don't know "why must zip or gz it" ).
can we after installing it simply zip up pristene ansible installation from what was installed on Ubuntu ? and later unzip this to a new host in order to get ansible working on new host ?
Not..... gracefully. I publish packaging tools to stay up-to-date for
ansible and ansible-core for RHEL systems, Step back to ansible-core,
which is well packaged for recent Ubuntu releases, and see if you
actually want or need the "ansible" package.
Thats great. And could likely use this as is , at times, sometimes… but the liklihood this gz bundle is exactly as we need it to be each time we need it, is not likely.
What would be the recipe to creat this so can add delete chane parts as needed.
I scrounged up this skeleton to create a remote installable archive to upgrade ancible on remote host. Would executing something similar to this as a playbook be part of how this gz is created ? Please comment. Thx
Thats great. And could likely use this as is , at times, sometimes... but the liklihood this gz bundle is exactly as we need it to be each time we need it, is not likely.
That's why pypi.org publishes these with release numbers, and for most
projects in the open source world the tag numbers are a reference to a
particular git commit.
I'm going to discourage you from trying to outsmart the people who
publish software releases for open source projects. You can spend a
lot of billable hours trying for additional layers of assurance, but
those additional layers often create their own instability.
What would be the recipe to creat this so can add delete chane parts as needed.
Don't use the "ansible" package. Use a stable "ansible-core", which is
where the ansible software really lives and is maintained, and use the
"ansible-galaxy" command with some scripting to insall specific
modules from the galaxy colledtions, if and only if needed.
I scrounged up this skeleton to create a remote installable archive to upgrade ancible on remote host. Would executing something similar to this as a playbook be part of how this gz is created ? Please comment. Thx
I'll suggest that you're re-inventing the wheel. Have some fun playing
with it if you like, strongly consider using only the packaged
"ansible-core" for your distribution, and install modules from the
ansible galaxy collections only as needed. You can get finicky about
managing *those* in a mirrored or replicated location if you feel the
need. But if you're already using ansible, why not let it do its job,
eat your own dog food, and use ansible to update the additional
modules?