shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day
"man podman-build" suggests that the context argument is optional:
SYNOPSIS
podman build [options] [context]
podman image build [options] [context]
...
If no context directory is specified, then Podman will assume
the current working directory as the build context, which
should contain the Containerfile.
but if i have a directory with nothing but a Containerfile, i get:
$ podman build
Error: no context directory specified, and no containerfile specified
$
OTOH, specifying context of current directory:
$ podman build .
STEP 1: FROM alpine:latest
... etc etc ...
thoughts?
rday
2 months, 2 weeks
image signing
by Hendrik Haddorp
Hi,
is OpenPGP the only supported image signing open supported by podman /
skopeo or are there other options? Using OpenGPG works quite fine for me
so far but in the end we are trying to sign an image using an IBM 4765
crypto card and so far have not figured out how this can play together.
thanks,
Hendrk
3 years, 11 months
Getting Docker Discourse running with Podman
by Philip Rhoades
People,
I can run the discourse image with docker, export the container and
import it as an image into podman.
The script that manages docker discourse containers is:
/var/discourse/launcher
and is attached. It would be good if it were possible to just replace
all the occurrences of "docker" with "podman", fix version numbers etc
and be able to use the script - but can any gurus see dockerisms in the
script that will cause podman gotchas for this idea?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
4 years, 1 month
Current status of podman on macOS Catalina?
by thomas.neal＠hcl.com
I have installed podman on my macOS Catalina laptop using 'brew cask install podman' and can see that I have v2.0.3 installed.
$ podman -v
podman version 2.0.3
$
From what I read, the macOS podman is a remote client, but I can't find consistent directions on how to setup/configure the macOS client to reference a remote podman node. I have both RHEL7.7 (podman version 1.6.4) and RHEL8.0 (podman version 1.9.3) VMs where I can ssh as root.
Can someone please point me to info about how to setup my macOS podman client to use either of my RHEL podman nodes?
Thanks in advance for any help!
4 years, 5 months
Re: Current status of podman on macOS Catalina?
by Thomas Neal
Daniel, is there an ETA for when that blog will be live?
--tom
Thomas Neal
Senior Software Developer
HCL Software DevOps
919-426-1259
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
4 years, 6 months
How to containerize a bash script that contains "podman run"?
by Erik Sjölund
I have a bash script that contains:
podman run --rm localhost/img1 prog1 somearg1
podman run --rm localhost/img2 prog2 otherarg1
It works just fine. The command-line tools prog1 and prog2
perform some calculations.
Now I would like to containerize the bash script and
run everything in a pod.
Do you have any tips on how to proceed?
One idea I had was to create a new container image based on
localhost/img1, but with the addition of a gRPC service or a Varlink
service for executing prog1. This service would make use of a Unix
domain socket. The same things would be done for localhost/img2.
Do you know of any tools that automate the writing of such a service
(i.e. a service that wraps a command-line tool)?
Socket activation and some exit-on-idle functionality would be cool
(but not so important).
(Socket activation might not be available in gRPC
https://github.com/grpc/grpc/issues/19133)
Thanks,
Erik
4 years, 6 months
podman error creating runtime static files
by Seth Kenlon
On RHEL 8 (CSB), I'm attempting to use podman. I've added myself to
/etc/sub{u,g}id, logged out and then back in. I've reinstalled
shadow-utils. Everything seems like it ought to work now, but no matter
what podman command I run, I seem to hit a runtime error.
```
$ podman --log-level debug image list
INFO[0000] running as rootless
ERRO[0000] Could not get runtime: error creating runtime static files
directory /var/lib/flatpak/exports/share:/containers/storage/libpod: mkdir
/var/lib/flatpak/exports/share:: permission denied
```
Running with `sudo` is successful, but I'm trying to avoid a `sudo`
dependency if possible.
Ultimately, I'd like to pull an image from quay.io via the podman Ansible
module, and I assume this error is why my playbook reliably fails at the
podman task.
4 years, 6 months
Podman API v1.0 Deprecation and Removal Notice
by Tom Sweeney
The Podman v1.0 API relied on the varlink library
(https://github.com/varlink/libvarlink) to handle the underlying
client/server calls from the Podman client to the host where the Podman
service was running. About one year ago, the Podman team was notified
that the varlink library was being deprecated and there would be no
further development and little support for it from the varlink library
team. This led the Podman team to investigate the use of other
client/server technologies and it was decided to develop a RESTful API
for Podman using the native Go libraries.
This new Podman v2.0 RESTful API was released along with Podman v2.0 in
June of 2020 and replaces the Podman API v1.0. As of that time the
Podman v1.0 API for Podman is considered to be deprecated. If there are
issues with the Podman v1.0 API in versions of Podman prior to v2.0 and
those versions are still under support on Red Hat Enterprise Linux
(RHEL), the Podman team will make a best effort to address those
issues. However, no new feature requests for the v1.0 API will be
considered and any problems found with the v1.0 API in Podman v2.0 will
not be addressed.
The new Podman v2.0 RESTful API is split into two halves: one providing
a Docker-compatible API, and a Libpod API providing support for Podman’s
unique features such as pods. The new API works in both a rootful and a
rootless environment. It is a much more flexible solution and Podman
will not have a dependency on another project in order to supply an
API. For more information on the Podman v2.0 RESTful API please see
articles on the podman.io site (https://podman.io/) and also the
documentation for the Podman v2.0 RESTful API
(http://docs.podman.io/en/latest/Reference.html).
Distributions have to support services for the length of their support
agreements. The Podman development team wants to be free to update the
version of Podman during this support cycle. Therefore, we are planning
to drop support for Podman API v1.0 from distributions Red Hats is the
packagers for. The version of Podman, 2.*, which is contained in
Fedora 33, scheduled to be released around Oct 31, 2020, will ship with
no varlink support. We also plan to drop support from the RHEL8.4
release, spring 2021. Other distributions like OpenSUSE have already
disabled varlink support and we have heard that other distributions will
follow suit.
This also serves as a notification that the Podman v1.0 (varlink) API
will be removed from the main GitHub branch of Podman in the near
future. With the release of Podman v2.0 the Podman developers
deprecated the Podman v1.0 API in favor of the new Podman v2.0 RESTful
API. The plan is to remove varlink completely from the Podman v3.0
development branch which will be created some time after September
2020. A 30 day notification of the final removal date will be posted on
the https://podman.iosite and also on the Podman mailing list, along
with social media once it is definitively determined.
If you have any questions or concerns about this notification, please
send a note to the Podman mailing list or create an issue on Podman’s
GitHub (https://github.com/containers/podman/issues) repository.
Note: This notice will be posted to the podman.io site early next week.
4 years, 6 months
