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
1 week, 4 days
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, 9 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
3 years, 11 months
Podman Community Meeting - Tues Nov 3, 2020 - 11:00 a.m. EST
by Tom Sweeney
Hi All,
Just a quick reminder that the next Podman Community Meeting is
happening next Tuesday November 3, 2020 at 11:00 a.m. EST (UTC-5). The
meeting is free to attend via BlueJeans video conferencing and is
scheduled for an hour.
Two quick notes:
o The US is turning the clocks back one hour this Sunday
November 1, so our UTC offset is shifting from -4 to -5.
o There's a little election going on in the USA on the meeting
date. If you're in the US and this time is the only time you can get
out and vote, please go vote. We'll be recording the meeting and you
can watch it after you vote.
The agenda is here: https://podman.io/community/meeting/agenda/ and
includes the BlueJeans link for the meeting and the HackMD link where
we'll take the meeting minutes.
Hope to see a bunch of you there!
t
4 years, 1 month
We have generated a new repo https://github.com/containers/shortnames
by Daniel Walsh
The goal is to collect shortnames of container images at particular
registries. Would love to get lists of images specific to
distributions. Prepopulated with the images from Fedora, since they
were fairly easy to gather.
Since the Repo is brand new please open PRs to fix up the README.md or
any problems that you see.
4 years, 2 months
Podman Community Meeting - Tuesday November 3, 2020 - 11:00 a.m. Eastern (UTC-05:00)
by Tom Sweeney
Hi All!
Just a quick reminder that the next Podman Community Meeting is coming
up two weeks from today, Tuesday November 3, 2020 at 11:00 a.m. Eastern
time (UTC-05:00). A couple notes about that. A) The USA is "falling
back" on Sunday November 1 to Eastern Standard Time. So our UTC offset
will be -05:00 instead of -04:00. B) Secondarily, there happens to be a
little election going on in the USA that day. If you are US based and
you have not voted by that time and the only time you can vote is during
the meeting time, please go vote. We will be recording this meeting so
you can replay it afterwards.
We have a couple of topics lined up for the meeting already. Anders
Bjorklund will be talking about boot2podman/podman-archive (basically a
varlink post-mortem) and Brent Baude will be talking about Red Hat's
perspective on the direction of the future design for Podman. We also
have some time set aside for Questions and Answers, so start thinking
of some questions that you'd like answered!
If by chance you have a topic that you would like to discuss or present
upon, please let me know. We might be able to add it to this meeting,
and if not, then for a future one.
We will again be using BlueJeans to video conference
(https://bluejeans.com/796412039) and we will also use HackMD to take
notes (https://hackmd.io/fc1zraYdS0-klJ2KJcfC7w). I will send out a
finalized agenda later next week. Like last time, no cost to attend.
Hope to see a bunch of you there!
t
4 years, 2 months
Building a Podman Jitsi Server
by Philip Rhoades
People,
I want to build this and from the Jitsi Manual Installation guide I have
marked up the attached diagram - can people see any issues with building
this container with Fedora and Podman? - has anyone tried it already? -
is anyone else interested in helping / co-operating?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
4 years, 2 months
locking down network access with proxy, app, and database scheme
by Peter Buffon
I'm currently looking for advice on using Podman to implement what I think
is a fairly common application scheme, deploying a WordPress instance with
a MariaDB backend and Nginx as a reverse-proxy.
Ideally I'd like to recreate a DMZ approach where the reverse proxy doesn't
have access to the database or any other containers on the host. I have
almost accomplished this with Docker Compose by attaching a frontend
network to the reverse proxy and the application containers and a backend
network to the application and database containers. This is a complicated
approach and doesn't solve the issue of all application containers being
accessible from the reverse proxy container.
I have tried two different approaches to accomplish something similar with
Podman, but they both ended with essentially the same result.
Method one: Enclose all three containers in a single pod. These pods can
access each other via localhost:port. This approach is not ideal because
the reverse proxy container has access to both the application and database
containers.
Method two: Create a new network, cni-podman0, with the dnsname CNI plugin
and each container is created in its own pod. This approach is also not
ideal because any container on the cni-podman0 network can access any other
container on the same network using the pod's name (even if containers and
pods do not have published ports).
Any suggestions on where to go from here? Could SELinux or BPF be possible
solutions or am I missing an easier solution? I also thought about
assigning IP addresses to each pod and using the firewall CNI plugin to
lock down access by IP and port, but limited documentation on integrating
Firewalld and Podman has limited me from experimenting further.
I realize Kubernete's service and network policy features essentially
solves this problem, but I am looking for a simplified single host approach
here.
Thanks,
Peter
4 years, 2 months
