[{"content":"There we go — the Red Hat—​IBM merger is now complete:\nAs #RedHat\u0026rsquo;s acquisition by @IBM closes, Red Hat will maintain independence and neutrality to give customers freedom, choice and flexibility. Get the news: https://t.co/ggZWYrT8ut pic.twitter.com/rw6hdvrqv7\n— Red Hat, Inc. (@RedHat) 9 lipca 2019\nThis is a pretty big deal. And I’m not talking about money only.\nRed Hat — a company as I know it I’m a Red Hatter since over 10 years now. I joined the company when it had just a little bit over 2k people. Now we have over 14k. Over all these years I saw how we grow. And we grew really fast. Especially in recent years.\nEveryone will tell you that Red Hat is about culture and not about material assets. And we really feel it, it’s not just talk for the public. We have a sense of contribute to what Red Hat is now.\nIt’s actually pretty hard to compare Red Hat with a standard(?) company. Red Hat is unique. Culture of openness is visible everywhere, on each level. I can talk with my manager about everything, I can have debates on technical (and not only!) aspects with anyone in the company, I’m never asked to be silent.\nI can have different view on things than the company does. I was not very happy with such big growth. Maintaining the sense of belonging to a family with such rapid growth is hard. But in the end I think we managed it pretty well.\nI have big confidence in Jim’s decisions. If you haven’t had chance to listen to Jim, do it. There are many interviews out there.\nSo, IBM.\nWait, what? IBM? When I heard for the first time that IBM is going to buy Red Hat — it was a shock to me and I wasn’t pleased with it, to say it politely. IBM is a very big company and its reputation is, well, not that nice. Everyone recognizes this company for great things that were done in the past but currently the blue light doesn’t really shine that bright.\nMany Red Hatters had similar feeling to me. Management knew it exactly — we made sure they know it. It’s an open organization after all!\nI can only imagine what questions our customers had. As company employees we had them too. Many of them. I’ll not describe what steps management took to explain to us the details of the merger, but they did a very good job, especially Jim.\nLife after merger There we are. One day after the deal is closed. So, what exactly will change? Nothing. And I’m really confident about it. You may ask why?\nIf IBM will do bad things to Red Hat — IBM will sink with it. As simple as this. It’s not about size of the company you buy, it’s more about what value it gives and what are the customer expectations related to it. And these are defined pretty clearly: Red Hat stays, we expect growth.\nPaying such huge amount of money (this is the biggest deal in software industry so far) for something you want to consume only would be very, very bad move. What would IBM get from it? Nothing.\nThe whole company, without any changes, is moved to IBM and will operate as distinct unit in the Hybrid Cloud team. Literally nothing changes in what we do and more importantly how we do it.\nJim and Ginni said numerous times that Red Hat will not be touched. Maybe I’m a little bit old-fashioned, but I trust in words that were said.\nWhat is the deal about? Have you thought what did IBM really bought here?\nProducts!\nNot really, they can have it for free.\nCustomer base?\nIBM’s is bigger.\nMaybe employees?\nOh, this is not easy. You cannot just buy Red Hatters. We are a very opinionated crowd, if something is not the Red Hat way many people will just resign. So, no, not employees.\nBuildings?\nFor $34 billions? These must be very expensive buildings…\nSo what it is?\nMy feeling is that IBM wants to work the Red Hat way. What is Red Hat way? This is how we work, collaborate, discuss. All default to open.\nIBM must and wants to change. IBM wants to be seen again as the company that innovates. Red Hat is required here, because IBM alone could not do it. You could try to do the process yourself, but it would take too much time, especially with a company of this size and the process would not be that visible to customers either.\nYou could change CEO, sure, but it does not work always as expected. Although there are exceptions.\nWhat’s the future then? It will be fine.\nIBM just cannot afford to screw this. I’m confident that Red Hat will stay Red Hat. And who knows — maybe IBM will become Red Hat.\nI look forward to see what’s next!\nP.S. I owe you another blog post explaining why I was quiet for so long time. I promise to write it shortly.\n","permalink":"https://goldmann.pl/blog/2019/07/10/red-hat-and-ibm/","summary":"\u003cp\u003eThere we go — the Red Hat—​IBM merger is now complete:\u003c/p\u003e\n\n\u003cblockquote\u003e\n  \u003cp\u003eAs \u003ca href=\"https://twitter.com/hashtag/RedHat?src=hash\u0026amp;ref_src=twsrc%5Etfw\"\u003e#RedHat\u003c/a\u003e\u0026rsquo;s acquisition by \u003ca href=\"https://twitter.com/IBM?ref_src=twsrc%5Etfw\"\u003e@IBM\u003c/a\u003e closes, Red Hat will maintain independence and neutrality to give customers freedom, choice and flexibility. Get the news: \u003ca href=\"https://t.co/ggZWYrT8ut\"\u003ehttps://t.co/ggZWYrT8ut\u003c/a\u003e \u003ca href=\"https://t.co/rw6hdvrqv7\"\u003epic.twitter.com/rw6hdvrqv7\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e— Red Hat, Inc. (@RedHat) \u003ca href=\"https://twitter.com/RedHat/status/1148570974637498368?ref_src=twsrc%5Etfw\"\u003e9 lipca 2019\u003c/a\u003e\u003c/p\u003e\n\n\u003c/blockquote\u003e\n\u003cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\"\u003e\u003c/script\u003e\n\u003cp\u003eThis is a pretty big deal. And I’m \u003cstrong\u003enot\u003c/strong\u003e talking about money only.\u003c/p\u003e\n\u003ch2 id=\"red-hata-company-as-i-know-it\"\u003eRed Hat — a company as I know it\u003c/h2\u003e\n\u003cp\u003eI’m a Red Hatter \u003ca href=\"https://twitter.com/marekgoldmann/status/1123228238438961153\"\u003esince over 10 years now\u003c/a\u003e.\nI joined the company when it had just a little bit over 2k people. Now we have over 14k. Over all these years\nI saw how we grow. And we grew \u003cem\u003ereally\u003c/em\u003e fast. Especially in recent years.\u003c/p\u003e","title":"Red Hat and IBM"},{"content":"TL;DR; I’m back!\nIt took a while. We didn’t see each other in long time. Probably too long. So, let me introduce myself again. I’m Marek. Since almost 10 years I work for the same company: Red Hat, in the Middleware part of it.\nOver that time I was working on various different technologies. Among other things it was: virtualization (KVM, IaaS), Fedora (RPM packaging), Cloud (OpenShift), Middleware (TorqueBox) and more.\nIf I would be tasked to select one technology that influenced my work the most — I would choose containers. This topic is close to everything I do in the last few years in a row.\nI touched (learned, used, you name it) different programming languages like: Ruby, Java, Groovy, Python and of course Bash.\nI was not only a programmer. I spent numerous hours on meetings and kind of tried to be a team lead of a very small group of three people.\nSo, who am I really? You may think: full stack developer, but I don’t necessarily like this name. DevOps? Maybe a little bit better. For sure I’m someone between a programmer, ops guy and team lead. It changes every day, depending on the tasks I need to do.\nExciting times really.\nRecently all this experience started to sparkle in my head the idea of returning back to digital life outside of my company.\nSo, I tweeted this:\nI\u0026rsquo;m considering bringing my feed alive. Anyone interested in topics close to my current work? Something between containers, OpenShift, CI/CD, guidelines, workflows, Jenkins. With occasional beer photos. And poor jokes. pic.twitter.com/UQnEhihlM0\n— Marek Goldmann (@marekgoldmann) 13 października 2018\nIt turned out that people are not against it.\nSo, here I am.\nAnd? You can expect more blog posts, of course. I expect that my blog will receive mostly technical posts. Occasionally there may be posted some other things, but not very often really.\nYou probably already noticed that the website itself got a refresh. I replaced my current static site generator with Hugo. There are still a few things that must be tweaked and the implementation is not as clean as I would like it to be, but the most important goal is already achieved: to make the content more readable.\nBesides this, I’m returning to my Twitter. This will be a mix of topics related to my work and my personal life. For sure you can expect topics mentioned in my tweet above and adventures with my race car (which I hope to drive more often).\nHello!\n","permalink":"https://goldmann.pl/blog/2018/10/14/hello-im-marek/","summary":"\u003cp\u003eTL;DR; \u003cstrong\u003eI’m back!\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt took a while. We didn’t see each other in long time. Probably too long. So, let me introduce myself again. \u003cspan class=\"mark\"\u003e\u003cstrong\u003eI’m Marek\u003c/strong\u003e\u003c/span\u003e. Since almost 10 years I work for the same company: \u003ca href=\"https://www.redhat.com/en\"\u003eRed Hat\u003c/a\u003e, in the \u003ca href=\"https://www.redhat.com/en/topics/middleware\"\u003eMiddleware part of it\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eOver that time I was working on various different technologies. Among other things it was: virtualization (KVM, IaaS), Fedora (RPM packaging), Cloud (OpenShift), Middleware (TorqueBox) and more.\u003c/p\u003e\n\u003cp\u003eIf I would be tasked to select one technology that influenced my work the most — \u003cspan class=\"mark\"\u003eI would choose \u003cstrong\u003econtainers\u003c/strong\u003e\u003c/span\u003e. This topic is close to everything I do in the last few years in a row.\u003c/p\u003e","title":"Hello, I'm Marek"},{"content":"In this blog post I would like to touch on the topic of resource management for Docker containers. It is often unclear how it works and what we can and cannot do. I hope that after reading this blog post resource management will be a bit easier for you to understand.\nNote\nI assume that you are running Docker on a systemd enabled operating system. If you are on RHEL/CentOS 7+ or Fedora 19+ this is certainly true. But please note that there can be some changes in the available configuration options between different systemd versions. When in doubt, use the systemd man pages for the system you work with.\nThe basics Docker uses cgroups to group processes running in the container. This allows you to manage the resources of a group of processes, which is very valuable, as you can imagine.\nIf we run an operating system which uses systemd as the service manager, every process (not only the ones inside of the container) will be placed in a cgroups tree. You can see it for yourself if you run the systemd-cgls command:\n$ systemd-cgls ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─machine.slice │ └─machine-qemu\\x2drhel7.scope │ └─29898 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name rhel7 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 2048 ├─system.slice │ ├─avahi-daemon.service │ │ ├─ 905 avahi-daemon: running [mistress.local │ │ └─1055 avahi-daemon: chroot helpe │ ├─dbus.service │ │ └─890 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation │ ├─firewalld.service │ │ └─887 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid │ ├─lvm2-lvmetad.service │ │ └─512 /usr/sbin/lvmetad -f │ ├─abrtd.service │ │ └─909 /usr/sbin/abrtd -d -s │ ├─wpa_supplicant.service │ │ └─1289 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplica │ ├─systemd-machined.service │ │ └─29899 /usr/lib/systemd/systemd-machined [SNIP] This approach gives a lot of flexibility when we want to manage resources, since we can manage every group individually. Although this blog post focuses on containers, the same principle applies to other processes as well.\nNote\nIf you want to read more about resource management with systemd I highly recommend the Resource Management and Linux Containers Guide for RHEL 7.\nA note on testing In my examples I’ll use the stress tool that helps me to generate some load in the containers so I can actually see the resource limits being applied. I created a custom Docker images called (surprisingly) stress using this Dockerfile:\nFROM fedora:latest RUN yum -y install stress \u0026amp;\u0026amp; yum clean all ENTRYPOINT [\u0026#34;stress\u0026#34;] A note on resource reporting tools The tools you are used to using to report usage like top, /proc/meminfo and so on are not cgroups aware. This means that they’ll report the information about the host even if we run them inside of a container. I found a nice blog post from Fabio Kung on this topic. Give it a read.\nSo, what can we do?\nIf you want to quickly find which container (or any systemd service, really) uses the most resources on the host I recommend the systemd-cgtop command:\n$ systemd-cgtop Path Tasks %CPU Memory Input/s Output/s / 226 13.0 6.7G - - /system.slice 47 2.2 16.0M - - /system.slice/gdm.service 2 2.1 - - - /system.slice/rngd.service 1 0.0 - - - /system.slice/NetworkManager.service 2 - - - - [SNIP] This tool can give you a quick overview of what’s going on on the system right now. But if you want to get some detailed information about the usage (for example you need to create nice graphs) you will want to parse the /sys/fs/cgroup/… directories. I’ll show you where to find useful files for each resource I will talk about (look at the CGroups fs paragraphs below).\nCPU Docker makes it possible (via the -c switch of the run command) to specify a value of shares of the CPU available to the container. This is a relative weight and has nothing to do with the actual processor speed. In fact, there is no way to say that a container should have access only to 1Ghz of the CPU. Keep that in mind.\nEvery new container will have 1024 shares of CPU by default. This value does not mean anything, when speaking of it alone. But if we start two containers and both will use 100% CPU, the CPU time will be divided equally between the two containers because they both have the same CPU shares (for the sake of simplicity I assume that there are no other processes running).\nIf we set one container’s CPU shares to 512 it will receive half of the CPU time compared to the other container. But this does not mean that it can use only half of the CPU. If the other container (with 1024 shares) is idle — our container will be allowed to use 100% of the CPU. That’s another thing to note.\nLimits are enforced only when they should be. CGroups does not limit the processes upfront (for example by not allowing them to run fast, even if there are free resources). Instead it gives as much as it can and limits only when necessary (for example when many processes start to use the CPU heavily at the same time).\nOf course it’s not easy (and I would say impossible) to say how many resources will be assigned to your process. It really depends on how other processes will behave and how many shares are assigned to them.\nExample: managing the CPU shares of a container As I mentioned before you can use the -c switch to manage the value of shares assigned to all processes running inside of a Docker container.\nSince I have 4 cores on my machine available, I’ll tell stress to use all 4:\n$ docker run -it --rm stress --cpu 4 stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd If we start two containers the same way, both will use around 50% of the CPU. But what happens if we modify the CPU shares for one container?\n$ docker run -it --rm -c 512 stress --cpu 4 stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd As you can see, the CPU is divided between the two containers in such a way that the first container uses ~60% of the CPU and the other ~30%. This seems to be the expected result.\nNote\nThe missing ~10% of the CPU was taken by GNOME, Chrome and my music player, in case you were wondering.\nAttaching containers to cores Besides limiting shares of the CPU, we can do one more thing: we can pin the container’s processes to a particular processor (core). To do this, we use the --cpuset switch of the docker run command.\nTo allow execution only on the first core:\ndocker run -it --rm --cpuset=0 stress --cpu 1 To allow execution only on the first two cores:\ndocker run -it --rm --cpuset=0,1 stress --cpu 2 You can of course mix the option --cpuset with -c.\nNote\nShare enforcement will only take place when the processes are run on the same core. This means that if you pin one container to the first core and the other container to the second core, both will use 100% of each core, even if they have different a CPU share value set (once again, I assume that only these two containers are running on the host).\nChanging the shares value for a running container It is possible to change the value of shares for a running container (or any other process, of course). You can directly interact with the cgroups filesystem, but since we have systemd we can leverage it to manage this for us (since it manages the processes anyhow).\nFor this purpose we’ll use the systemctl command with the set-property argument. Every new container created using the docker run command will have a systemd scope automatically assigned under which all of its processes will be executed. To change the CPU share for all processes in the container we just need to change it for the scope, like so:\n$ sudo systemctl set-property docker-4be96b853089bc6044b29cb873cac460b429cfcbdd0e877c0868eb2a901dbf80.scope CPUShares=512 Note\nAdd --runtime to change the setting temporarily. Otherwise, this setting will be remembered when the host is restarted.\nThis changes the default value from 1024 to 512. You can see the result below. The change happens somewhere in the middle of the recording. Please note the CPU usage. In systemd-cgtop 100% means full use of 1 core and this is correct since I bound both containers to the same core.\nNote\nTo show all properties you can use the systemctl show docker-4be96b853089bc6044b29cb873cac460b429cfcbdd0e877c0868eb2a901dbf80.scope command. To list all available properties take a look at man systemd.resource-control.\nCGroups fs You can find all the information about the CPU for a specific container under /sys/fs/cgroup/cpu/system.slice/docker-$FULL_CONTAINER_ID.scope/, for example:\n$ ls /sys/fs/cgroup/cpu/system.slice/docker-6935854d444d78abe52d629cb9d680334751a0cda82e11d2610e041d77a62b3f.scope/ cgroup.clone_children cpuacct.usage_percpu cpu.rt_runtime_us tasks cgroup.procs cpu.cfs_period_us cpu.shares cpuacct.stat cpu.cfs_quota_us cpu.stat cpuacct.usage cpu.rt_period_us notify_on_release Note\nMore information about these files can be found in the RHEL Resource Management Guide. This information is spread across the cpu, cpuacct and cpuset sections.\nRecap A few things to remember:\na CPU share is just a number — it’s not related to the CPU speed\nBy default new containers have 1024 shares\nOn an idle host a container with low shares will still be able to use 100% of the CPU\nYou can pin a container to specific core, if you want\nMemory Now let’s take a look at limiting memory.\nThe first thing to note is that a container can use all of the memory on the host with the default settings.\nIf you want to limit memory for all of the processes inside of the container just use the -m docker run switch. You can define the value in bytes or by adding a suffix (k, m or g).\nExample: managing the memory shares of a container You can use the -m switch like so:\n$ docker run -it --rm -m 128m fedora bash To show that the limitation actually works I’ll use my stress image again. Consider the following run:\n$ docker run -it --rm -m 128m stress --vm 1 --vm-bytes 128M --vm-hang 0 stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd The stress tool will create one process and try to allocate 128MB of memory to it. It works fine, good. But what happens if we try to use more than we have actually allocated for the container?\n$ docker run -it --rm -m 128m stress --vm 1 --vm-bytes 200M --vm-hang 0 stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd It works too. Surprising? Yes I agree.\nWe can find the explanation for this in the libcontainer source code (Docker’s interface to cgroups). We can see there that by default the memory.memsw.limit_in_bytes value is set to twice as much as the memory parameter we specify while starting a container. What does the memory.memsw.limit_in_bytes parameter say? It is a sum of memory and swap. This means that Docker will assign to the container -m amount of memory as well as -m amount of swap.\nThe current Docker interface does not allow us to specify how much (or disable it entirely) swap should be allowed, so we need live with it for now.\nWith the above information we can run our example again. This time we will try to allocate over twice the amount of memory we assign. This should use all of the memory and all of the swap, then die.\n$ docker run -it --rm -m 128m stress --vm 1 --vm-bytes 260M --vm-hang 0 stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd stress: FAIL: [1] (415) \u0026lt;-- worker 6 got signal 9 stress: WARN: [1] (417) now reaping child worker processes stress: FAIL: [1] (421) kill error: No such process stress: FAIL: [1] (451) failed run completed in 5s If you try once again to allocate for example 250MB (--vm-bytes 250M) it will work just fine.\nWarning\nIf we don’t limit the memory by using -m switch the swap size will be unlimited too.1\nHaving no limit on memory can lead to issues where one container can easily make the whole system unstable and as a result unusable. So please remember: always use the -m parameter 2.\nCGroups fs You can find all the information about the memory under /sys/fs/cgroup/memory/system.slice/docker-$FULL_CONTAINER_ID.scope/, for example:\n$ ls /sys/fs/cgroup/memory/system.slice/docker-48db72d492307799d8b3e37a48627af464d19895601f18a82702116b097e8396.scope/ cgroup.clone_children memory.memsw.failcnt cgroup.event_control memory.memsw.limit_in_bytes cgroup.procs memory.memsw.max_usage_in_bytes memory.failcnt memory.memsw.usage_in_bytes memory.force_empty memory.move_charge_at_immigrate memory.kmem.failcnt memory.numa_stat memory.kmem.limit_in_bytes memory.oom_control memory.kmem.max_usage_in_bytes memory.pressure_level memory.kmem.slabinfo memory.soft_limit_in_bytes memory.kmem.tcp.failcnt memory.stat memory.kmem.tcp.limit_in_bytes memory.swappiness memory.kmem.tcp.max_usage_in_bytes memory.usage_in_bytes memory.kmem.tcp.usage_in_bytes memory.use_hierarchy memory.kmem.usage_in_bytes notify_on_release memory.limit_in_bytes tasks memory.max_usage_in_bytes Note\nMore information about these files can be found in the RHEL Resource Management Guide, memory section.\nBlock devices (disk) With block devices we can think about two different types of limits:\nRead/write speed\nAmount of space available to write (quota)\nThe first one is pretty easy to enforce, whereas the second is still unsolved.\nNote\nI assume you are using the devicemapper storage backed for Docker. Everything below may be untrue for other backends.\nLimiting read/write speed Docker does not provide any switch that can be used to define how fast we can read or write data to a block device. But CGroups does have it built-in. And it’s even exposed in systemd via the BlockIO* properties.\nTo limit read and write speed we can use the BlockIOReadBandwidth and BlockIOWriteBandwidth properties, respectively.\nBy default the bandwith is not limited. This means that one container can make the disk hot, especially if it starts to swap…\nExample: limiting write speed Let’s measure the speed with no limits enforced:\n$ docker run -it --rm --name block-device-test fedora bash bash-4.2# time $(dd if=/dev/zero of=testfile0 bs=1000 count=100000 \u0026amp;\u0026amp; sync) 100000+0 records in 100000+0 records out 100000000 bytes (100 MB) copied, 0.202718 s, 493 MB/s real 0m3.838s user 0m0.018s sys 0m0.213s It took 3.8 sec to write 100MB of data which gives us about 26MB/s. Let’s try to limit the disk speed a bit.\nTo be able to adjust the bandwitch available for the container we need to know exactly where the container filesystem is mounted. You can find it when you execute the mount command from inside of the container and find the device that is mounted on the root filesystem:\n$ mount /dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88 on / type ext4 (rw,relatime,context=\u0026#34;system_u:object_r:svirt_sandbox_file_t:s0:c447,c990\u0026#34;,discard,stripe=16,data=ordered) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev type tmpfs (rw,nosuid,context=\u0026#34;system_u:object_r:svirt_sandbox_file_t:s0:c447,c990\u0026#34;,mode=755) [SNIP] In our case this is /dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88.\nYou can also use the nsenter command to get this value, like so:\n$ sudo /usr/bin/nsenter --target $(docker inspect -f \u0026#39;{{ .State.Pid }}\u0026#39; $CONTAINER_ID) --mount --uts --ipc --net --pid mount | head -1 | awk \u0026#39;{ print $1 }\u0026#39; /dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88 Now we can change the value of the BlockIOWriteBandwidth property, like so:\n$ sudo systemctl set-property --runtime docker-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88.scope \u0026#34;BlockIOWriteBandwidth=/dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88 10M\u0026#34; This should limit the disk write speed to 10MB/s, so let’s run dd again:\nbash-4.2# time $(dd if=/dev/zero of=testfile0 bs=1000 count=100000 \u0026amp;\u0026amp; sync) 100000+0 records in 100000+0 records out 100000000 bytes (100 MB) copied, 0.229776 s, 435 MB/s real 0m10.428s user 0m0.012s sys 0m0.276s It seems to work, it took 10s to write 100MB to the disk, so the speed was about 10MB/s.\nNote\nThe same applies to limiting the read bandwith with the difference being you use the BlockIOReadBandwidth property.\nLimiting disk space As I mentioned before this is tough topic. By default you get 10GB of space for each container. Sometimes this is too much, sometimes we cannot fit all of our data there. Unfortunately there is not much we can do about it now.\nThe only thing we can do is to change the default value for new containers. If you think that some other value (for example 5GB) is a beter fit in your case, you can do it by specifying the --storage-opt for the Docker daemon, like so:\ndocker -d --storage-opt dm.basesize=5G You can tweak some other things, but please keep in mind that it requires restarting the Docker daemon afterwards. More info can be found in the readme.\nCGroups fs You can find all the information about the block devices under /sys/fs/cgroup/blkio/system.slice/docker-$FULL_CONTAINER_ID.scope/, for example:\n$ ls /sys/fs/cgroup/blkio/system.slice/docker-48db72d492307799d8b3e37a48627af464d19895601f18a82702116b097e8396.scope/ blkio.io_merged blkio.sectors_recursive blkio.io_merged_recursive blkio.throttle.io_service_bytes blkio.io_queued blkio.throttle.io_serviced blkio.io_queued_recursive blkio.throttle.read_bps_device blkio.io_service_bytes blkio.throttle.read_iops_device blkio.io_service_bytes_recursive blkio.throttle.write_bps_device blkio.io_serviced blkio.throttle.write_iops_device blkio.io_serviced_recursive blkio.time blkio.io_service_time blkio.time_recursive blkio.io_service_time_recursive blkio.weight blkio.io_wait_time blkio.weight_device blkio.io_wait_time_recursive cgroup.clone_children blkio.leaf_weight cgroup.procs blkio.leaf_weight_device notify_on_release blkio.reset_stats tasks blkio.sectors Note\nMore information about these files can be found in the RHEL Resource Management Guide, blkio section.\nSummary As you can see resource management for Docker containers is possible. It’s even pretty easy. The only thing that bothers me (and others too) is that we cannot set a quota for disk usage. There is an issue filled upstream — watch it and comment.\nHope you found my post useful. Happy dockerizing!\nThis is technically not true; there is a limit, but it’s set to a value that is not reachable in the systems we currently run. For example on my laptop with 16GB of ram the value is 18446744073709551615 which is ~18.5 exabytes…\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOr just use the MemoryLimit property.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://goldmann.pl/blog/2014/09/11/resource-management-in-docker/","summary":"\u003cp\u003eIn this blog post I would like to touch on the topic of resource management for Docker\ncontainers. It is often unclear how it works and what we can and\ncannot do. I hope that after reading this blog post resource management will\nbe a bit easier for you to understand.\u003c/p\u003e\n\n\u003cblockquote class=\"alert alert-note\"\u003e\n  \u003cp class=\"alert-heading\"\u003eNote\u003c/p\u003e\n  \u003cp\u003eI assume that you are running Docker on a systemd enabled operating system. If\nyou are on RHEL/CentOS 7+ or Fedora 19+ this is certainly true. But please note\nthat there can be some changes in the available configuration options between\ndifferent systemd versions. When in doubt, use the systemd man pages for the system you\nwork with.\u003c/p\u003e","title":"Resource management in Docker"},{"content":"Starting and stopping Docker containers is easy with the docker run and docker {stop|kill} commands. By default, when the Docker daemon is restarted, running containers are also restarted. This is a great feature but sometimes you need more control over the container’s lifecycle.\nImagine having a container which is linked to another one. Docker does not provide any way of specifying which container should be started when or what to do if a container dies.\nDeployment scenario Consider this pretty simple deployment:\nWhen we start such a deployment we need to ensure that the database is started first, so we can later link it to the WildFly node.\nNote\nThe load balancer set up is not part of this guide, but is shown (along with another WildFly node) using a dotted outline. The mod_cluster project may be a good choice for a load balancer.\nWe’ll use following images to power this setup:\nfedora/mariadb for the the database\na custom image based on jboss/wildfly to run the node\nsystemd to the rescue Systemd is a system management daemon which replaced SysV init scripts in Fedora some time ago. The systemd project provides a very flexible and powerful way to manage services. This is a really big project and all the various use cases for it make it a bit hard to understand. Luckily our deployment is very simple to implement in systemd.\nTo be able to manage a service with systemd we need to create a service file for it. In our case a service is equal to a running container.\nThe docker-mariadb service Let’s create a docker-mariadb.service file for the database container:\n[Unit] Description=MariaDB database Requires=docker.service After=docker.service [Service] User=goldmann Restart=on-failure RestartSec=10 ExecStartPre=-/usr/bin/docker kill mariadb ExecStartPre=-/usr/bin/docker rm mariadb ExecStart=/usr/bin/docker run --name=mariadb fedora/mariadb ExecStop=-/usr/bin/docker stop mariadb [Install] WantedBy=multi-user.target This file should be stored in the /etc/systemd/system/multi-user.target.wants/ directory.\nNote\nIn this example all data will be lost when you remove the mariadb container. You may want to look at various options for managing data in containers.\nService file explained Let’s now go through the docker-mariadb.service file:\nThe [Unit] section contains information about the service itself. Here you can find the Description which will be visible almost everywhere (try systemctl list-units).\nThe Requires parameter specifies which service should be activated and marked to be started before our service. In our case (if we want to start/enable the docker-mariadb.service) the docker.service service will be started/enabled too.\nThe After parameter configures the ordering of services. In our case the docker-mariadb.service will wait for the docker.service to start and only then will it be started. If we don’t provide the After parameter, our service would be started in parallel with the docker.service. This could trigger some issues because there is some chance that the Docker service would be not fully started, when we try to run the container.\nThe [Service] section defines the actual service.\nThe User parameter specifies the user that will be used to execute the command. This is optional but it’s a good idea to keep user privileges as minimal as possible.\nThe Restart parameter specifies when the service should be restarted. The on-failure value means that the service will be restarted when the service is terminated in an unclean way. The RestartSec parameter specifies how long we should wait before we try to restart the service.\nThe Environment parameter is useful to set environment variables for the processes that will be started. I use it to lower the memory requirements of the JVM for WildFly (see below).\nThe ExecStartPre parameters specify which command should be run before we start the main process. I use it to clean up (stop and remove) containers. Please note the minus sign just before the command. This tells systemd to not fail the boot even if the command fails.\nThe ExecStart parameter is the heart of the service. Here we define what should be started to run our service.\nThe ExecStop parameter is similar to ExecStart, but will run if we want to stop the service.\nThe [Install] section defines the configuration used at service install time.\nThe WantedBy parameter specifies that our service should be started when the multi-user target is reached. Since this particular target is the default, we enable our service by default.\nNote\nIf you want to learn more about systemd a good place to start is the systemd.service and systemd.unit man pages. The systemd homepage has a lot of resources too, including nice blog posts for administrators.\nThe docker-wildfly service Now we create a similar docker-wildfly.service file for the WildFly application server:\n[Unit] Description=WildFly node Requires=docker-mariadb.service After=docker-mariadb.service [Service] User=goldmann Restart=on-failure RestartSec=10 Environment=\u0026#34;JAVA_OPTS=-Xms64m -Xmx512m\u0026#34; ExecStartPre=-/usr/bin/docker kill wildfly-mariadb ExecStartPre=-/usr/bin/docker rm wildfly-mariadb ExecStart=/usr/bin/docker run --name wildfly --link mariadb:mariadb -p 8080:8080 wildfly-mariadb ExecStop=-/usr/bin/docker stop wildfly-mariadb [Install] WantedBy=multi-user.target Again, place it in the /etc/systemd/system/multi-user.target.wants/ directory.\nThis file is similar to the first, but with one very important difference: the After and Requires parameters specify the docker-mariadb service. This is because we want to boot WildFly after the MariaDB database.\nIf you want to run WildFly on multiple nodes, just copy the file and edit appropriate values (node name).\nNote\nAlthough it is possible to run multiple containers from one systemd service file (hint: Type=oneshot and RemainAfterExit=true) I recommend you have one service per container. This way you’ll have better control over them.\nThe wildfly-mariadb image In the service above we used the wildfly-mariadb Docker image. The Dockerfile and instructions on how to build it are available on GitHub.\nEnable and run the service To be able to enable or start the service, systemd needs to be reloaded to pick up our new service files. Run:\n$ systemctl daemon-reload This command will also mark our service to be started on boot (remember the WantedBy parameters?). Now we can start our application:\n$ systemctl start docker-wildfly To confirm that everything worked, run:\n$ systemctl status docker-wildfly $ docker ps Now you can point your browser to http://localhost:8080/wildfly-kitchensink/ and everything should work.\nNote\nif you use systemd to start the containers on boot, it’s a good idea to disable the buit-in Docker functionaly by copying the /usr/lib/systemd/system/docker.service to /etc/systemd/system/multi-user.target.wants/docker.service and adding the following switch: --restart=false to the Docker daemon in the ExecStart line. Do not forget to reload the systemd daemon afterwards.\nDisable and remove the service When using custom scripts (like we do) we cannot use the systemctl disable commands (this is by systemd design — if you want know more please read this comment). In our case we need to remove (or rename) the docker-*.service files and then run:\n$ systemctl reset-failed Summary This was just a small introduction to the Docker and systemd world. I hope you can leverage it to run your services since it’s a pretty good choice. I should mention here the geard project which aims to do what I described above (and much, much more).\n","permalink":"https://goldmann.pl/blog/2014/07/30/runninng-docker-containers-as-systemd-services/","summary":"\u003cp\u003eStarting and stopping Docker containers is easy with the \u003ccode\u003edocker run\u003c/code\u003e and\n\u003ccode\u003edocker {stop|kill}\u003c/code\u003e commands. By default, when the Docker daemon is restarted,\nrunning containers are also restarted. This is a great feature but sometimes\nyou need more control over the container’s lifecycle.\u003c/p\u003e\n\u003cp\u003eImagine having a container which is linked to another one. Docker does not\nprovide any way of specifying which container should be started when or what to do\nif a container dies.\u003c/p\u003e","title":"Runninng Docker containers as systemd services"},{"content":"Default configuration is a great place to start with a project. We at JBoss try to make our projects (and products too!) usable out-of-box for as many use cases as we can, but there is no way that one configuration could satisfy everyone’s needs. For example, we ship 4 flavors of the standalone.xml configuration file with WildFly since there are so many different deployment scenarios. But this is still not enough. We need to be able to tweak it at any point. The jboss/wildfly image is not an exception here.\nFollowing the Docker recreate — do not modify principle we do change the configuration by creating a new image (in most cases). This allows us to reuse the images (consider the jboss/wildfly image itself).\nOf course this is not the only way to modify the WildFly configuration, so let’s iterate over available options.\nUpdate 24.07.2014\nOne of the readers brought up that I forgot to mention one great tool: Augeas. I’ve added it now to the list and summary.\nTL;DR; See summary.\nBoot time configuration Using command line parameters (or environment variables) is the simplest way to modify the default configuration. This does not require rebuilding the image but is not persistent. Still, in many cases it is the best approach.\nThere is one obvious limitation: only a limited set of things can be modified. WildFly allows us to customize parameters with the switches for the standalone.sh or domain.sh startup scripts. The WildFly documentation has a great summary of the available options.\nCommand line parameters With the jboss/wildfly image it’s easy to use command line parameters. Just override the default command when launching the container, for example:\ndocker run -it jboss/wildfly /opt/wildfly/bin/domain.sh -b 0.0.0.0 -Djboss.management.http.port=8888 This launches WildFly in domain mode (instead of standalone), binds the public endpoint to every interface, and exposes the management endpoint on port 8888 (by default bound to 127.0.0.1).\nNote\nYou can create your own image which overrides only the command to run. Use the CMD instruction in Dockerfile.\nEnvironment variables Specifying environments variables with Docker is easy too:\ndocker run -it -e JBOSS_LOG_DIR=/opt/wildfly/logs jboss/wildfly And now all logs will be saved to the /opt/wildfly/logs directory.\nNote\nYou can modify environment variables in Docker images too. Use the ENV instruction in Dockerfile.\nExplore the --env-file parameter of docker run if you want to set many environment variables.\nsed Note\nThis example is available on GitHub.\nThe sed command may be used in your Dockerfile to modify some (small) parts of the configuration. Please note that WildFly stores configuration in XML format so you will need to be careful when using sed :)\nThere are possible use cases for sed, for example when you want to disable the coloring on the console:\nsed -i \u0026#39;s|named-formatter name=\u0026#34;COLOR-PATTERN\u0026#34;|named-formatter name=\u0026#34;PATTERN\u0026#34;|\u0026#39; /opt/wildfly/standalone/configuration/standalone.xml In general no, I do not recommend using sed because using regular expressions may be tricky, especially if you’re not familiar with them.\nxmlstarlet Note\nThis example is available on GitHub.\nThe xmlstarlet tool is a set of commands that can be helpful when interacting with XML files. In our case one command is especially useful: xmlstarlet ed which is used to modify XML documents.\nLet’s say we want to change the root-logger level to DEBUG:\nxmlstarlet ed -L -u \u0026#34;//*[local-name()=\u0026#39;root-logger\u0026#39;]/*/@name\u0026#34; -v \u0026#34;DEBUG\u0026#34; /opt/wildfly/standalone/configuration/standalone.xml You can place the above in your Dockerfile and call it done.\nAlthough xmlstarlet is nice at finding (using XPath) and editing attributes or elements, it’s not a great tool to add complex elements. It can become easily very verbose. If you don’t trust sed but still want to tweak some elements, use xmlstarlet instead!\nThe jboss/wildfly image contains the xmlstarlet utility installed by default (as of July 23rd).\nXSLT transformations Note\nThis example is available on GitHub.\nXSLT transformations are a nice way to execute conditional modifications of the WildFly application server configuration. The WildFly team provides examples of xsl files. You can use Saxon to execute the transformation:\njava -jar /usr/share/java/saxon.jar -s:/opt/wildfly/standalone/configuration/standalone.xml -xsl:/opt/wildfly/customization/changeIPAddresses.xsl -o:/opt/wildfly/standalone/configuration/standalone.xml publicIPAddress=0.0.0.0 In this example we change the default binding address of the server for public ports.\nFor more information about using the Saxon utility from the CLI, please refer to the documentation.\nThe jboss/wildfly image contains the saxon package installed by default (as of July 23rd).\nUsing jboss-cli.sh Note\nThis example is available on GitHub.\nWildFly ships with a powerful CLI. The documentation contains a few examples of how the CLI can be used. Of course the CLI is perfect to modify the server configuration.\nTo be able to modify the configuration the WildFly server needs to be running. Since at the build time of a Docker image based on jboss/wildfly (in most cases) we do not start WildFly, this can be a problem.\nOne solution is to boot WildFly, execute the CLI commands and shutdown the server. I used this approach in my example. It adds a new ExampleMySQLDS datasource to the server. The main file that does the job is the execute.sh script:\n#!/bin/bash JBOSS_HOME=/opt/wildfly JBOSS_CLI=$JBOSS_HOME/bin/jboss-cli.sh JBOSS_MODE=${1:-\u0026#34;standalone\u0026#34;} JBOSS_CONFIG=${2:-\u0026#34;$JBOSS_MODE.xml\u0026#34;} function wait_for_server() { until `$JBOSS_CLI -c \u0026#34;ls /deployment\u0026#34; \u0026amp;\u0026gt; /dev/null`; do sleep 1 done } echo \u0026#34;=\u0026gt; Starting WildFly server\u0026#34; $JBOSS_HOME/bin/$JBOSS_MODE.sh -c $JBOSS_CONFIG \u0026gt;dev/null \u0026amp; echo \u0026#34;=\u0026gt; Waiting for the server to boot\u0026#34; wait_for_server echo \u0026#34;=\u0026gt; Executing the commands\u0026#34; $JBOSS_CLI -c --file=`dirname \u0026#34;$0\u0026#34;`/commands.cli echo \u0026#34;=\u0026gt; Shutting down WildFly\u0026#34; if [ \u0026#34;$JBOSS_MODE\u0026#34; = \u0026#34;standalone\u0026#34; ]; then $JBOSS_CLI -c \u0026#34;:shutdown\u0026#34; else $JBOSS_CLI -c \u0026#34;/host=*:shutdown\u0026#34; fi The script is general purpose and can be reused in some other images. It can modify the configuration for any WildFly operating mode and for any configuration.\nThe commands.cli file contains commands executed in the CLI.\n# Mark the commands below to be run as a batch batch # Add MySQL driver /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql.jdbc,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource) # Add the datasource data-source add --name=UnifiedPushDS --driver-name=mysql --jndi-name=java:jboss/datasources/ExampleMySQLDS --connection-url=jdbc:mysql://localhost:3306/sample?useUnicode=true\u0026amp;amp;characterEncoding=UTF-8 --user-name=user --password=password --use-ccm=false --max-pool-size=25 --blocking-timeout-wait-millis=5000 --enabled=true # Execute the batch run-batch The CLI approach is very powerful and flexible. The only caveat is that WildFly needs to be running to use the CLI.\nUsing custom configuration files Note\nThis example is available on GitHub.\nThe last approach is to simply maintain a separate configuration file for WildFly. Just ADD your configuration to the /opt/wildfly/{standalone|domain}/configuration directory and override the default boot command. You can for example remove some subsystems like I did in the example.\nThis is the simplest and cleanest approach. This way you have full control over the configuration at any time. The bad thing is that you need to maintain the file yourself. If a new version of WildFly will be released — you need to manually apply the changes to the configuration.\nAugeas Note\nThis example is available on GitHub.\nAugeas is a general purpose configuration editing tool. It has plugins (lenses) for many configuration files. If your file isn’t on the list — don’t worry — you can use some generic lenses. In our case it’ll be the Xml lens.\nAugeas builds a tree of the file loaded. Just take a look at the example where we change the root-logger (and cosnole-handler) level to DEBUG.\naugtool -LA -e \u0026lt;\u0026lt;EOF set /augeas/load/Xml/lens Xml.lns set /augeas/load/Xml/incl[2] /opt/wildfly/standalone/configuration/standalone.xml load defvar subsystem \u0026#34;/files/opt/wildfly/standalone/configuration/standalone.xml/server/profile/subsystem[#attribute/xmlns=\u0026#39;urn:jboss:domain:logging:2.0\u0026#39;]\u0026#34; set $subsystem/console-handler/level/#attribute/name \u0026#34;DEBUG\u0026#34; set $subsystem/root-logger/level/#attribute/name \u0026#34;DEBUG\u0026#34; save EOF It looks like XPath, but is much simpler. In previous exmaple we modified the attribute but it’s easy to add new elements too. Let’s add a TRACE log level for our pl.goldmann.example category:\nset $subsystem/logger[last()+1]/#attribute/category \u0026#34;pl.goldmann.example\u0026#34; set $subsystem/logger[last()]/level/#attribute/name \u0026#34;TRACE\u0026#34; The first command adds a new \u0026lt;logger/\u0026gt; element with pl.goldmann.example as the category attribute and the next line adds a new \u0026lt;level/\u0026gt; element under the previously created \u0026lt;logger/\u0026gt; and sets the name atrtibute to TRACE. Isn’t nice?\nAugeas is definitely a project worth to become familiar with. Above was just a tiny example of what it can do.\nThe jboss/wildfly image contains the augeas utility installed by default (as of July 24rd).\nSummary Every approach has pros and cons. Boot time configuration is great if you want to change some exposed parameters. The sed and xmlstarlet options are similar providing a simple way to change some parts of the configuration. But this is not flexible. XSLT transformations are very powerful, but they require some amount of work to write the stylesheets properly. The jboss-cli.sh aproach is very good if you don’t mind starting and stopping WildFly at the build time. Maintaining own configuration file at the first glance looks like a best solution and probably it is in some cases. If you want to do have a powerful yet simple way of changing the configuration — use Augeas.\nWhat’s your approach?\n","permalink":"https://goldmann.pl/blog/2014/07/23/customizing-the-configuration-of-the-wildfly-docker-image/","summary":"\u003cp\u003eDefault configuration is a great place to start with a project. We at JBoss try\nto make our \u003ca href=\"http://www.jboss.org/projects/\"\u003eprojects\u003c/a\u003e (and\n\u003ca href=\"http://www.jboss.org/products/\"\u003eproducts\u003c/a\u003e too!) usable out-of-box for as\nmany use cases as we can, but there is no way that one configuration could\nsatisfy everyone’s needs. For example, we ship 4 flavors of the \u003ccode\u003estandalone.xml\u003c/code\u003e\nconfiguration file with \u003ca href=\"http://wildfly.org/\"\u003eWildFly\u003c/a\u003e since there are so\nmany different deployment scenarios. But this is still not enough. We need to be able to\ntweak it at any point. The \u003ccode\u003ejboss/wildfly\u003c/code\u003e image is not an exception here.\u003c/p\u003e","title":"Customizing the configuration of the WildFly Docker image"},{"content":"There are various ways to set up logging for Docker containers. Docker itself has a built-in logs command, you can mount a volume from the host and save the logs there, you can create a different container that would be only responsible for log handling, or set up a logging daemon. Every method has some pros and cons and it is up to you to choose the one that fits best.\nLet’s go through each of these options, learn a litle about the it, and modify the jboss/wildfly image use it.\nNote\nI won’t talk about WildFly logging in general, in this blog post I’ll focus on the required changes (if any) to make it work inside a container. If you’re interested in the logging subsystem configuration, please refer to the documentation.\nTL;DR; Don’t use docker logs in production. Mounting volumes from a host is simple but could be tricky, especially if you run SELinux. If you set it up correctly, you’ll be happy. Using data containers is fun and probably a good way to do logging. If you need more control, set up a logging daemon.\nExamples are available on GitHub.\ndocker logs The logs command is a handy feature of Docker. If the process you run inside of the container prints something to standard output (or standard error) - the message is saved in a log and available for reading later.\nUsing docker logs is the simplest way to read logs from a container.\n# Start the container and save the container ID ID=$(docker run -d jboss/wildfly) # Use the ID to read the logs from the selected container docker logs -f $ID This approach is nice if you want to see what’s going on inside of the container. I do not recommend using it in production as the only way of logging. You may ask why? Every line of the output is saved in a JSON formatted file (see /var/lib/docker/containers/$ID/$ID-json.log) accompanied by a bit of metadata (timestamp for example, where most logs include it anyway). The log file can grow pretty quickly, especially if you have a lot of messages. Grepping JSON is not much fun either. Additionally stacktraces are split line-by-line.\nIf this is not an issue for you - go for it.\nNote\nYou can access logs from a stopped container too, which is a plus.\nIn the jboss/wildfly image, we didn’t change the default logging configuration. Everything that goes to the console will be available using the docker logs command.\nYou can change this behavior by customizing the /opt/wildfly/standalone/configuration/standalone.xml file (if you actually use the default standalone profile). For example you can remove the CONSOLE handler entirely to stop printing anything to the console.\nMounting a volume from the host Mounting a volume from the host and exposing it in the container is another way to store logs. In this case every file written to the directory will be immediately available on the host. This way you can have multiple containers saving logs to the host’s directory (which may be very handy in some cases).\nNote\nThe biggest issue with this approach is that it is not portable. You need to setup the directories once again when you move to another host.\nPermission denied If you use the -v switch from the docker run command and try to mount a non-existent directory from the host — a new directory will be created on the host with root as the owner and 755 permissions making it not writable for any other user than root inside of the container. The jboss/wildfly image does use the wildfly user to run the Java process, so it will not be able to store logs in the mounted directory.\nOf course there is a way to make it work.\nLet’s make it writable The trick is to have a user with the same uid/gid both in the container and on the host.\nThe jboss/wildfly image uses a wildfly user with a well known user uid/gid (431/433) to run the server. We can use this information and create a wildfly-logs user on the host with the same uid/gid. This will make the mounted volume available to read/write operations for the wildfly user inside of the container.\nRun on the host:\ngroupadd -r wildfly-logs -g 433 useradd -u 431 -r -g wildfly-logs -s /sbin/nologin -c \u0026#34;WildFly container logs\u0026#34; wildfly-logs Cool, now we have the user, let’s create the directory we will mount later in the container.\nmkdir /opt/logs/wildfly-01 chown wildfly-logs:wildfly-logs /opt/logs/wildfly-01 chcon -t svirt_sandbox_file_t /opt/logs/wildfly-01 Please note the last command. We need to change the SELinux label to svirt_sandbox_file_t for this directory so the Docker daemon can write to it. You can read more about SELinux and Docker on the Project Atomic website.\nNow we can start the container with the volume mounted in /opt/wildfly/standalone/log.\ndocker run -d -v /opt/logs/wildfly-01:/opt/wildfly/standalone/log jboss/wildfly Note\nThe same wildfly-logs user can be used for any jboss/wildfly containers, because each container has a wildfly user created with the particular uid/gid.\nRead more about using Docker volumes in the documentation.\nAfter you boot the container, you can go to the /opt/logs/wildfly-01 directory on the host. You should find the server.log file there.\nUsing a data container This is a variation of the logging to a mounted host directory approach. In this case instead of mounting a directory from host we use another container’s exposed volume. Such containers are called data containers. Their responsibility is to hold some data. You can use one container to save logs from many other containers. As a plus, this approach is portable — you can take your containers and launch them on a different host and everything will work.\nThe data container image Note\nAll files are available on GitHub.\nFirst we need to prepare an image that will be used to launch a container where we want to store our logs.\nFROM jboss/wildfly RUN mkdir -p /opt/wildfly/logs VOLUME /opt/wildfly/logs CMD true Save the above snippet as Dockerfile and build it with docker build --rm --tag=data ..\nNote\nThe CMD instruction above is not a mistake. To use the exposed volumes from a container it doesn’t need to be actually running. After executing the true command the container will be stopped, but we’ll still have access to the volumes.\nYou may wonder why we extend the jboss/wildfly image in first place and not use a clean fedora image. The reason is that the jboss/wildfly image already has a wildfly user created. As I mentioned above, the same user will be used to launch the Java processes and if we mount a volume owned by this user, it will be available for writing. We don’t waste any disk space by using this approach, because Docker uses a copy-on-write filesystem.\nLet’s run our data container:\ndocker run --name data data Exported volumes and paths Mounted data volumes are visible under the same path as they were exported. This means that if we export the /opt/wildfly/logs volume in the data container and mount it in our WildFly container — it’ll be visible under the /opt/wildfly/logs path there too.\nNote\nThis is not strictly true if you try to export a path that is actually a symlink. In such cases the resolved path will be exported, not the symlink, so in our case it will be /opt/wildfly-8.1.0.Final/logs instead of /opt/wildfly/logs, but this won’t change anything for us.\nSometimes having a single location mounted in many containers under same path is desirable (for example database data), but in our case (logging from multiple WildFly containers) it would cause problems. Imagine an exported /opt/wildfly/standalone/log volume being mounted in many WildFly containers at the same time…\nThere are many solutions; for example you can change the WildFly configuration to log to different directories or you can just symlink the /opt/wildfly/standalone/log directory to some /opt/wildfly/logs subdirectory in the way it makes sense for you.\nIn this blog post I’ll show how to use the first solution.\nModifying the WildFly image Note\nAll files are available on GitHub.\nNow we create a new image that extends the jboss/wildfly image. The change we want to make is to modify the configuration that controls where the logs are stored:\nFROM jboss/wildfly RUN sed -i \u0026#39;s|\u0026lt;file relative-to=\u0026#34;jboss.server.log.dir\u0026#34; path=\u0026#34;server.log\u0026#34;/\u0026gt;|\\\u0026lt;file relative-to=\u0026#34;jboss.home.dir\u0026#34; path=\u0026#34;logs/\\${jboss.host.name}/server.log\u0026#34;/\\\u0026gt;|\u0026#39; /opt/wildfly/standalone/configuration/standalone.xml This simple sed call changes the default location of the log file. We make the path host aware by using the jboss.host.name property. At the time of launching the container we have full control over the hostname. We can us the -h switch from the docker run command to specify the host name or just leave it as-is and jboss.host.name will be resolved to the shortened container id.\nLet’s build the image:\ndocker build --rm --tag wildfly-logs . And finally launch it:\ndocker run -d -h wildfly-01 --name wildfly-01 --volumes-from data wildfly-logs We can launch even more containers and all of them will save logs in our data container:\ndocker run -d -h wildfly-02 --name wildfly-02 --volumes-from data wildfly-logs docker run -d -h wildfly-03 --name wildfly-03 --volumes-from data wildfly-logs Getting access to the logs We log from all our containers to one place, cool, but how to get access to those logs? It’s not so hard:\ndocker run -it --rm --volumes-from data -v `pwd`:/backup fedora sh -c \u0026#39;cp -r /opt/wildfly-8.1.0.Final/logs /backup \u0026amp;\u0026amp; chown -R 1000:1000 /backup/\u0026#39; This (somewhat lengthy) command will start a new container with the current directory mounted as /backup and the exported volume from the data container mounted in its path. Then it copies all the logs from the exported volume to our local directory and changes ovnership of these files to my local user. This way we can have full control over these files. My local account has a uid/gid of 1000, so this works for me. You’ll probably need to adjust the uid/gid to match your own.\nNote\nDo not forget to chcon -t svirt_sandbox_file_t . the directory where you want to store the logs locally so the the copy can be performed.\n$ ls -hall logs/* logs/wildfly-02: total 16K drwxr-xr-x. 2 goldmann goldmann 4,0K 07-16 16:12 . drwxr-xr-x. 4 goldmann goldmann 4,0K 07-16 16:12 .. -rw-r--r--. 1 goldmann goldmann 4,9K 07-16 16:12 server.log logs/wildfly-03: total 12K drwxr-xr-x. 2 goldmann goldmann 4,0K 07-16 16:12 . drwxr-xr-x. 4 goldmann goldmann 4,0K 07-16 16:12 .. -rw-r--r--. 1 goldmann goldmann 3,9K 07-16 16:12 server.log Exactly what we needed!\nLogging daemon Logging to a file is nice, but sometimes you need to manage logging in a more powerful way. The are many solutions available like syslog-ng, rsyslog, or logstash. No matter which one you choose, they’re all pretty flexible and easy to set up.\nI would like to show you how to set up a syslog-ng daemon (running in a container) with the jboss/wildfly Docker image.\nsyslog-ng image Note\nAll files are available on GitHub.\nThe first step is to prepare the syslog-ng Docker image.\nFROM fedora RUN yum -y install syslog-ng \u0026amp;\u0026amp; yum clean all ADD syslog-ng.conf /etc/syslog-ng/syslog-ng.conf VOLUME /var/log/wildfly EXPOSE 514/udp CMD [\u0026#34;/usr/sbin/syslog-ng\u0026#34;, \u0026#34;-F\u0026#34;, \u0026#34;--no-caps\u0026#34;] And here is the simple syslog-ng.conf:\n@version:3.4 options { flush_lines (0); time_reopen (10); log_fifo_size (1000); chain_hostnames (off); use_dns (no); use_fqdn (no); create_dirs (no); keep_hostname (yes); }; source s_sys { udp(ip(0.0.0.0) port(514)); }; destination d_wildfly { file(\u0026#34;/var/log/wildfly/$HOST.log\u0026#34; template(\u0026#34;$ISODATE $PRIORITY $MSG\\n\u0026#34;) template_escape(no)); }; log { source(s_sys); destination(d_wildfly); }; This is a very simple syslog-ng configuration file. When a new message arrives, it will be saved to a file corresponding to the hostname the message comes from. And since we can easily change the hostname of our containers, we will immediatelly know which container logged what.\nBuild the image with docker build --rm --tag syslog ..\nNote\nI need to mention that the true power in this (or any other) logger solution is to be able to filter and route the selected messages. The above example is just a start, don’t be afraid to extend it!\nWe can start the logging container and proceed to the next step.\ndocker run -d --name syslog syslog Modifying the WildFly image Note\nAll files are available on GitHub.\nSince logging to syslog is not enabled by default we need to modify our WildFly configuration to let the server know where the syslog-ng daemon is listening.\nTo do this we need to add the syslog-handler to the logging subsystem in the /opt/wildfly/standalone/configuration/standalone.xml file:\n\u0026lt;syslog-handler name=\u0026#34;SYSLOG\u0026#34;\u0026gt; \u0026lt;level name=\u0026#34;INFO\u0026#34;/\u0026gt; \u0026lt;hostname value=\u0026#34;${jboss.host.name}\u0026#34; /\u0026gt; \u0026lt;server-address value=\u0026#34;${env.SYSLOG_PORT_514_UDP_ADDR}\u0026#34; /\u0026gt; \u0026lt;port value=\u0026#34;514\u0026#34; /\u0026gt; \u0026lt;formatter\u0026gt;\u0026lt;syslog-format syslog-type=\u0026#34;RFC3164\u0026#34;/\u0026gt;\u0026lt;/formatter\u0026gt; \u0026lt;/syslog-handler\u0026gt; And enable it:\n\u0026lt;handlers\u0026gt; \u0026lt;handler name=\u0026#34;SYSLOG\u0026#34;/\u0026gt; \u0026lt;/handlers\u0026gt; The above configuration will make sure we send the messages to the proper destination. We use the SYSLOG_PORT_514_UDP_ADDR environment variable to determine the IP address of the host where syslog-ng is running. More on this variable in a bit.\nNow you need to build the image:\ndocker build --rm --tag wildfly-syslog . That’s all. Now you need to run one or more wildfly-syslog containers. All of them will be saving logs to the syslog container over UDP.\ndocker run -d --link syslog:syslog wildfly-syslog The --link switch will create environment variables based on what the syslog container is exposing, and it exposes the 514 UDP port. Docker will create the SYSLOG_PORT_514_UDP_ADDR environment variable (and many others) for us which will tell us the IP where the syslog container is running. The Docker links feature if a great way to make containers talk to each other without hardcoding the connection parameters.\nAccessing logs In the above example we still log everything to files. If you would like to receive them from the syslog container you can use a similar method as described in the Getting access to the logs section above.\nSummary As you can see, logging in a container can be easy and powerful at the same time. You need to choose the best option for you. There is no golden mean.\nI hope this blog post will help you manage your logs. If you have ny ideas on how to make the logging easier with the jboss/wildfly image, feel free to leave a comment or file a ticket.\n","permalink":"https://goldmann.pl/blog/2014/07/18/logging-with-the-wildfly-docker-image/","summary":"\u003cp\u003eThere are various ways to set up logging for Docker containers. Docker itself\nhas a built-in \u003ccode\u003elogs\u003c/code\u003e \u003cstrong\u003ecommand\u003c/strong\u003e, you can \u003cstrong\u003emount a volume\u003c/strong\u003e from the host and save\nthe logs there, you can create a \u003cstrong\u003edifferent container\u003c/strong\u003e that would be\nonly responsible for log handling, or set up a \u003cstrong\u003elogging daemon\u003c/strong\u003e. Every method\nhas some pros and cons and it is up to you to choose the one that fits best.\u003c/p\u003e","title":"Logging with the WildFly Docker image"},{"content":"I recently announced the availability of the official WildFly Docker image. Since then, our portfolio of images has grown a bit - as of today, we have 8 images. But this is not the end. We want to have a nice collection of JBoss projects shipped as Docker images.\nAutomated builds All of our images are hooked up to automated builds. When we push an update to the repository, a new image will be created and pushed to the global registry. I also set up links between the images so if a base image is updated, our dependent images will be rebuilt. This is a fully automated process that ensures you get the latest available software.\nDocker microsite Today I’m happy to announce the Docker dedicated microsite on jboss.org.\nWe crafted the http://jboss.org/docker website to show, in one place, all the images we currently ship. It additionally provides basic information about each project and detailed information about each image.\nOf course, the list of all repositories is also available from hub.docker.com!\nHelp us to help you! We’re happy to add new images! You can even help us by opening a pull request or just let us know what projects you would like to see in the portfolio. Do not hesitate to create bug reports (if you find any) too!\n","permalink":"https://goldmann.pl/blog/2014/07/08/jboss-projects-as-docker-images/","summary":"\u003cp\u003e\u003ca href=\"https://twitter.com/marekgoldmann/status/474867431736082432\"\u003eI recently\nannounced the availability\u003c/a\u003e of the official \u003ca href=\"http://wildfly.org/\"\u003eWildFly\u003c/a\u003e\nDocker image. Since then, \u003ca href=\"https://hub.docker.com/u/jboss/\"\u003eour\nportfolio of images has grown a bit\u003c/a\u003e - as of today, we have 8 images. But this\nis not the end. We want to have \u003cstrong\u003ea nice collection\u003c/strong\u003e of JBoss projects shipped as\nDocker images.\u003c/p\u003e\n\u003ch2 id=\"automated-builds\"\u003eAutomated builds\u003c/h2\u003e\n\u003cp\u003eAll of our images are hooked up to\n\u003ca href=\"https://docs.docker.com/docker-hub/builds/\"\u003eautomated builds\u003c/a\u003e. When we push\nan update to \u003ca href=\"https://github.com/jboss/dockerfiles\"\u003ethe repository\u003c/a\u003e, a new\nimage will be created and pushed to the global registry. I also set up links\nbetween the images so if a base image is updated, our dependent images will be\nrebuilt. This is a fully \u003cstrong\u003eautomated\u003c/strong\u003e process that ensures you get the latest\navailable software.\u003c/p\u003e","title":"JBoss projects as Docker images"},{"content":"The default way of creating an image with Docker is to extend an image by using the FROM call in the Dockerfile. But this is not the only way to do this. You can easily create a base image by using only the yum command.\nWildFly 8.0.0.Final was recently released and is now available in Fedora 20 updates-testing repository. Let’s create an image that could be used to test this release but make it as minimal as it could be. The application server does have a lot of dependencies, so do not expect a 100 MB image. It’ll be closer to 1 GB.\nIntro One difference between virtual machines and Docker images is that a virtual machine need to contain its own kernel to be able to run. This is not the case in Docker since we reuse the host kernel (which is already running).\nThe following analogy may help:\nVirtual machines — whole PC with graphic card, CPU, disk, controllers,\nDocker images — only the disk.\nYou can move around and launch either, but virtual machines are way heavier.\nThis means that we can create an image with only the required bits and drop everything else — making it easier to maintain, lighter and of course more secure. An example of such an image is busy box. The current virtual image size is ~2.5 MB. Less than nothing.\nTo create such a small image we need to use an external tool and not extend a base image. As I mentioned before in our case we will use the yum command.\nBuilding the image I prepared and ran the following script:\n#!/bin/bash if [ $UID -ne 0 ]; then echo \u0026#34;You need to run this script as root\u0026#34; exit 1 fi NAME=wildfly-minimal BUILDDIR=`pwd`/build # Removing the earlier build rm -rf $BUILDDIR # Install the required stuff yum -y install wildfly \\ --setopt=override_install_langs=en \\ --setopt=tsflags=nodocs \\ --installroot $BUILDDIR \\ --disablerepo=* \\ --enablerepo=fedora,updates,updates-testing \\ --releasever=20 \\ --nogpgcheck # Clean up the cache # and fix the console issue when running the image chroot $BUILDDIR /bin/bash -x \u0026lt;\u0026lt;EOF rm -rf /var/cache/yum/* rm -rf /dev/console ln -s /dev/tty1 /dev/console EOF # Import to Docker tar -C $BUILDDIR -c . | docker import - $NAME That’s all. Now you can run your image. The image ID was printed after import. In my case it was 05c926b5dc99d5c4edc6eb6bfb7040d6b4bc67e1f00f3f9af4485dffefe21a66. Time to run it:\ndocker run -i -t 05c926b5 /usr/share/wildfly/bin/standalone.sh -b 0.0.0.0 Now that we have a running WildFly server, let’s point the browser to it. But what’s the address? It’s easy to get this information too!\nFirst execute the docker ps command to get the container ID:\n$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES af59785a5245 wildfly-minimal:latest /usr/share/wildfly/b About a minute ago Up About a minute tender_euclid Now we can use the docker inspect command to get the IP address:\n$ docker inspect -f \u0026#39;{{ .NetworkSettings.IPAddress }}\u0026#39; af59785a5245 172.17.0.2 Great, WildFly is available on http://172.17.0.2:8080.\nUpdate 07.06.2014 I changed a bit the script. Now it installs only the en language files and there was a mistake in cleaning the YUM cache which is now fixed too. Additionally I fixed the /dev/console warning messages that were appearing on boot.\nEverything above made it possible to decrease the size of the image from 1.6GB to 1GB. Win!\n","permalink":"https://goldmann.pl/blog/2014/03/06/creating-a-minimal-wildfly-docker-image/","summary":"\u003cp\u003eThe default way of creating an image with Docker is to extend an image by\nusing the \u003ccode\u003eFROM\u003c/code\u003e call in the \u003ccode\u003eDockerfile\u003c/code\u003e. But this is not the only way to do\nthis. You can easily create a base image by using only the \u003ccode\u003eyum\u003c/code\u003e command.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://wildfly.org/\"\u003eWildFly\u003c/a\u003e \u003ccode\u003e8.0.0.Final\u003c/code\u003e\n\u003ca href=\"http://wildfly.org/news/2014/02/11/WildFly8-Final-Released/\"\u003ewas recently released\u003c/a\u003e\nand is now available in Fedora 20 \u003ccode\u003eupdates-testing\u003c/code\u003e repository. Let’s\ncreate an image that could be used to test this release but make it as minimal\nas it could be. The application server does have a lot of dependencies, so do\nnot expect a 100 MB image. It’ll be closer to 1 GB.\u003c/p\u003e","title":"Creating a minimal WildFly Docker image"},{"content":" Warning\nThis guide is based on an old version of Docker. The instructions you find below may be already removed or changed in the Docker codebase.\nIn my last blog post I explained how to run a Docker installation across multiple hosts. In the comments I was asked if it would be possible to use a DHCP server to assign IPs to the containers. I thought immediately — why not? In fact, assigning IPs using DHCP is a nice way to overcome the IP assignment issue I talked about before.\nSet up The set up is pretty similar to my earlier work.\nThe difference is that I want to run a DHCP server on each of the hosts. It will be responsible for assigning the IPs to all of the containers connected to the docker0 bridge on that host.\nYou may ask why I want to run so many DHCP servers? Of course one server would do the job of assigning the IP’s (in fact, this was my initial set-up). Then I realized that it would be easier to manage routing of the container’s traffic if we have a DHCP server on every host.\nSince we want to have the containers run on the same network, there will be many DHCP servers working on that network. The trick is to reserve a bunch of IP’s for each host so as not to interfere with other hosts (in my case it’s 10 addresses per host) and drop the DHCP requests on each br0 Open vSwitch bridge.\nNew scripts Additionally I rewrote my earlier script that prepares the virtual machines for me. I decided to drop the use of cloud-init entirely in favor of libguestfs — a great Swiss Army knife written by Rich. If you’re not familiar with it — it’s a tool for offline manipulation of disk images. And it does the job damn well.\nYou can install libguestfs tools on your system by running this command:\nyum -y install libguestfs-tools Install liguestfs-tools before you use my scripts.\nNote\nThe first run of guestfish can take a bit, since it creates the supermin appliance. Also, if you run it in a virtualized environment it will perform a bit worse compared to bare metal.\nThe new scripts are avilable in the docker-dhcp repository on GitHub.\nThe logic of preparing and registering the image as a libvirt domain was split into two scripts:\nprepare-image.sh — update the system, modify the image,\nregister-domain.sh — copy the image to a custom location and register a domain under the new name.\nThe split made it possible to create the image once and create as many domains as you want in seconds.\nI placed a lot of comments in these scripts, so I hope everything is self-explaining. Let me know if that’s not the case!\nBase image To create a VM with everything preinstalled to make the setup easier the only thing you need to do is to download the QCOW2 image from cloud.fedoraproject.org and run the script providing the cloud image as the parameter, like this:\n$ ./prepare-image.sh Fedora-x86_64-20-20131211.1-sda.qcow2 Wed, 29 Jan 2014 12:20:57 +0100 Cleaniung up... Wed, 29 Jan 2014 12:20:58 +0100 Modifying the image... Wed, 29 Jan 2014 12:25:15 +0100 Resizing the disk... Wed, 29 Jan 2014 12:26:06 +0100 Image \u0026#39;image.qcow2\u0026#39; created! Note\nExecuting the above script can take some time. It took about 5 minutes for me to prepare the image. Please keep in mind that it does the full system update and it installs some additional software as well.\nThis script injects the network.sh script which will be used later to configure the network inside the hosts.\nHost domains Now we have the base image prepared: image.qcow2. Time to make use of it and register two domains based on it. For this purpose I use the register-domain.sh script:\n$ ./register-domain.sh image.qcow2 host1 Wed, 29 Jan 2014 13:52:51 +0100 Installing the domain and adjusting the configuration... Wed, 29 Jan 2014 13:52:51 +0100 Domain host1 registered! Wed, 29 Jan 2014 13:52:51 +0100 Launching the host1 domain... Wed, 29 Jan 2014 13:52:52 +0100 Domain started, waiting for the IP... Wed, 29 Jan 2014 13:53:30 +0100 You can ssh to the 192.168.122.144 host using \u0026#39;fedora\u0026#39; username and \u0026#39;fedora\u0026#39; password or use the \u0026#39;virsh console host1\u0026#39; command to directly attach to the console You can log-in using the fedora / fedora credentials.\nNote\nIf you don’t want to run the domain immediately after creation — use the RUN_AFTER environment variable and set it to false.\nRun the register-domain.sh script twice with host1 and host2 as the arguments.\nDHCP configuration explained The DHCP server will be run on every host and listen only for requests on the docker0 interface since it’s configured to look for the 172.16.42.0/24 network only. The first 9 IP addresses from this network are reserved (can be assigned manually to additional hosts), the rest will be available to the DHCP clients.\nEvery DHCP server will only be responsible for a part of the network. For example, the server on host1 will assign addresses from 172.16.42.10 to 172.16.42.19, whereas host2 will will assign addresses from 172.16.42.20 to 172.16.42.29.\nNote\nThis is just an example — you can expand the default values to run more than 10 containers on one host.\nThe host1 docker0 network interface will have the 172.16.42.1 address assigned, host2 will have 172.16.42.2, and so on.\nMake it work! I assume that we have already started host1 and host2 as explained above.\nNetworking Now it’s time to prepare the networking on both hosts. Log-in to both hosts and get the IP addresses of the eth0 network interfaces. Now run the network.sh script (it’s located in the /home/fedora directory) on both hosts.\nNote\nI assume that host1 has 192.168.122.31 IP and host2 has 192.168.122.2.\nOn host1 run the script with the IP of host2:\n$ sudo ./network.sh 1 192.168.122.2 And do the opposite on host2:\n$ sudo ./network.sh 2 192.168.122.31 Note\nWhen you run the network.sh script for the first time, you may see messages similar to bridge docker0 doesn’t exist — don’t worry, this is normal.\nThe GRE tunnel should now be established and a DHCP server should be running on host1. You can confirm this by pinging the docker0 bridge addresses on each host.\nContainers There is one requirement for the container image — it needs to have a DHCP client installed. Sadly the default fedora image does not have the dhclient package installed. To make things easy I prepared the goldmann/fedora-dhcp image. The only difference between fedora image is the addition of dhclient.\nDownload this image on both hosts:\ndocker pull goldmann/fedora-dhcp If you run the goldmann/fedora-dhcp image you’ll see that there is no network interfaces beside the loopback. This is because Docker is run with the -b=none flag and it does not know about any network interfaces to bind to, so it does not create the ethernet adapter in the container.\nBut we still want to have networking. The only option at the moment is to use the -lxc-conf flag when running the image, like this:\ndocker run -i -t \\ -lxc-conf=\u0026#34;lxc.network.type = veth\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.link = docker0\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.flags = up\u0026#34; \\ goldmann/fedora-dhcp /bin/bash This will start a new container with a virtual ethernet adapter which is attached to the docker0 bridge. Sweet!\nObtaining the IP address Since the Docker container does not run anything besides the command you specify (in our case /bin/bash) — it does not run the scripts that configures the network too. We need to do it by hand.\nNote\nI hope this will change in the near future. One option is to make systemd run well in the Docker containers.\nAfter you get the prompt from the container, you can simply run the dhclient command. This will obtain the address from the DHCP server, exit and leave a shell just for you.\nbash-4.2# ip a s dev eth0 17: eth0: \u0026lt;BROADCAST,MULTICAST,UP,LOWER_UP\u0026gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 1e:d4:13:c7:9d:fd brd ff:ff:ff:ff:ff:ff inet6 fe80::1cd4:13ff:fec7:9dfd/64 scope link valid_lft forever preferred_lft forever bash-4.2# dhclient bash-4.2# ip a s dev eth0 17: eth0: \u0026lt;BROADCAST,MULTICAST,UP,LOWER_UP\u0026gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 1e:d4:13:c7:9d:fd brd ff:ff:ff:ff:ff:ff inet 172.16.42.14/24 brd 172.16.42.255 scope global dynamic eth0 valid_lft 43197sec preferred_lft 43197sec inet6 fe80::1cd4:13ff:fec7:9dfd/64 scope link valid_lft forever preferred_lft forever bash-4.2# ping -c 1 google.com PING google.com (173.194.65.139) 56(84) bytes of data. 64 bytes from ee-in-f139.1e100.net (173.194.65.139): icmp_seq=1 ttl=39 time=55.6 ms --- google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 55.672/55.672/55.672/0.000 ms Note\nYou can also use the /etc/init.d/network restart command to obtain the IP.\nYou can (should!) try it on host1 and host2. You should get the same result with no IP conflict and be able to access the Internet as well as other containers on the network.\nEnjoy!\nThings to improve There are of course some things that could be improved to make this setup easier.\nMake systemd available in the container — this would boot the networking and get the IP address automatically for us. Stop Docker from (blindly) assigning IP addresses when we specify the -b=BRIDGE flag. Docker currently assumes that it manages the container network and nothing else is allowed to do so. I hope this will change in the future. ","permalink":"https://goldmann.pl/blog/2014/01/30/assigning-ip-addresses-to-docker-containers-via-dhcp/","summary":"\u003cblockquote class=\"alert alert-warning\"\u003e\n  \u003cp class=\"alert-heading\"\u003eWarning\u003c/p\u003e\n  \u003cp\u003eThis guide is based on an old version of Docker. The instructions you\nfind below may be already removed or changed in the Docker codebase.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eIn my\n\u003ca href=\"/blog/2014/01/21/connecting-docker-containers-on-multiple-hosts/\"\u003elast blog\npost\u003c/a\u003e I explained how to run a Docker installation across multiple hosts.\nIn the comments I was asked if it would be possible to use a DHCP server to\nassign IPs to the containers. I thought immediately — why not? In fact,\nassigning IPs using DHCP is a nice way to overcome the\n\u003ca href=\"/blog/2014/01/21/connecting-docker-containers-on-multiple-hosts/#_the_issue_ip_assignment\"\u003eIP\nassignment issue I talked about before\u003c/a\u003e.\u003c/p\u003e","title":"Assigning IP addresses to Docker containers via DHCP"},{"content":" Warning\nThis guide is based on an old version of Docker. The instructions you find below may be already removed or changed in the Docker codebase.\nIn my previous blog post I talked about running the Fedora Cloud images on a local KVM with libvirt. This was not a standalone task, but rather the preparation for this blog post: running Docker containers on multiple hosts attached to the same network.\nI was asked in the comments on my WildFly cluster based on Docker blog post if it would be possible to run a cluster on multiple hosts. I found a very nice tutorial written by Franck Besnard. I’ve decided to set up a similar environment on my own to see how/if it works.\nI made a few changes to Franck’s set up:\nI’m not using the pipework script to minimize the dependencies.\nI wanted to make the launching of the containers as simple as possible, so I dropped the use of the ovswork.sh script Franck crafted and I only use the docker run command.\nI’m not creating a virtual ethernet device for each container — instead I’m attaching all containers to a bridge.\nI’m not using VLAN’s (yet)\nSet up I used two VM’s (host1 and host2) each with Fedora 20 as the operating system. You can use the script I described in my previous post to create them. Later you can use the virsh start host1 command to run them.\nDocker On both hosts I’ve installed Docker:\nyum -y install docker-io The Docker configuration requires some changes.\nBy default Docker chooses a (more or less) random network to run the containers. After this it creates a bridge and assigns an address to it. This is not really what we want because we need to have static address assignment, so we need to prepare our own bridge and disable the one managed by Docker.\nCopy the /usr/lib/systemd/system/docker.service file to /etc/systemd/system/docker.service and add following content to disable the default docker0 bridge creation on Docker startup.\n.include /usr/lib/systemd/system/docker.service [Service] ExecStart= ExecStart=/usr/bin/docker -d -b=none You can start Docker with systemctl start docker.\nNote\nEvery time you modify a systemd service file do not forget to run systemctl daemon-reload to apply your changes.\nNetworking This is the interesting part :)\nOpen vSwitch To make networking easy I used the Open vSwitch software. I’m very new to it, but its flexibility and ease of use is just impressive. I haven’t done any performance testing, though. Maybe some day.\nYou can install Open vSwitch on Fedora by running this command:\nyum -y install openvswitch Network configuration The script below prepares the networking for you. You can execute it on both hosts by adjusting the REMOTE_IP and BRIDGE_ADDRESS variables. The BRIDGE_NAME can be the same on both hosts.\n# The \u0026#39;other\u0026#39; host REMOTE_IP=192.168.122.189 # Name of the bridge BRIDGE_NAME=docker0 # Bridge address BRIDGE_ADDRESS=172.16.42.2/24 # Deactivate the docker0 bridge ip link set $BRIDGE_NAME down # Remove the docker0 bridge brctl delbr $BRIDGE_NAME # Delete the Open vSwitch bridge ovs-vsctl del-br br0 # Add the docker0 bridge brctl addbr $BRIDGE_NAME # Set up the IP for the docker0 bridge ip a add $BRIDGE_ADDRESS dev $BRIDGE_NAME # Activate the bridge ip link set $BRIDGE_NAME up # Add the br0 Open vSwitch bridge ovs-vsctl add-br br0 # Create the tunnel to the other host and attach it to the # br0 bridge ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=$REMOTE_IP # Add the br0 bridge to docker0 bridge brctl addif $BRIDGE_NAME br0 # Some useful commands to confirm the settings: # ip a s # ip r s # ovs-vsctl show # brctl show After executing these commands on both hosts you should be able to ping the docker0 bridge addresses from both hosts.\nHere is an example from host2 (ip 192.168.122.189):\n$ ping 172.16.42.1 PING 172.16.42.1 (172.16.42.1) 56(84) bytes of data. 64 bytes from 172.16.42.1: icmp_seq=1 ttl=64 time=2.16 ms 64 bytes from 172.16.42.1: icmp_seq=2 ttl=64 time=0.628 ms ^C --- 172.16.42.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.628/1.396/2.165/0.769 ms Networking explained The above script has some useful comments that help to understand what it’s doing, but here’s a high level view on the networking part.\nEvery container run with Docker is attached to docker0 bridge. This is a regular bridge you can create on every Linux system, without the need for Open vSwitch.\nThe docker0 bridge is attached to another bridge: br0. This time it’s an Open vSwitch bridge. This means that all traffic between containers is routed through br0 too. You can think about two switches connected to each other.\nAdditionally we need to connect together the networks from both hosts in which the containers are running. A GRE tunnel is used for this purpose. This tunnel is attached to the br0 Open vSwitch bridge and as a result to docker0 too.\nThe issue: IP assignment While creating this environment I found a problem.\nDocker assumes that it’s managing the network where the containers are run. It does not expect any other hosts to be run on the network besides the ones it starts. This works well in a typical environment (and definitely makes the code easier). But if we’re going to spread across multiple hosts — this can cause some headaches.\nDocker address assignement method The way Docker assignes IP addresses to the containers is very simple: it tries to assign the first unused address. It sounds valid, right? But it depends how do you define not used. When Docker starts a container — the assigned IP is added to a list of used IPs maintained by the Docker daemon. Not used IP in Docker’s case means that the IP wasn’t found in that list.\nThis can be problematic, though. If you run something manually on that network and you assign an IP to it — Docker will not be able to detect it and instead it can happen that Docker assigns this IP blindly again causing a conflict.\nSolution Over the weekend I was thinking about some solutions, and I ended up with two:\nObvious one: change the Docker code to find out if the address is really free.\nManually assign IP’s to the containers when running them.\nBoth have pros and cons. There may be other solutions too. Feel free to drop a comment if you find one.\nOption 1: Modifying Docker The first idea involves patching Docker. We need to make it aware of the hosts running on the network. From the beginning I was focused on using the ARP protocol.\nI was trying to use the host ARP cache table for the interface bound to Docker (by default it’s docker0), but I found that:\nContainers do not advertise themselves on startup, and Even if we advertise manually (using gratuitous ARP message) — the ARP table is not reliable enough since entries will be removed after some time if there is no communication between these two hosts. Note\nFedora does drop the broadcast ARP messages by default. You can change this by setting: echo 1 \u0026gt; /proc/sys/net/ipv4/conf/\u0026lt;device\u0026gt;/arp_accept. Read more in the Linux kernel documentation (search for arp_accept).\nBut the good news is that we still can find if the selected IP is used by using the arping utility and this is what I used.\nI prepared a very ugly patch for Docker 0.7.6 which adds an additional check if the IP we’re trying to use is actually free.\nIn my testing I found that using arping is pretty reliable — the hosts were discovered properly and it didn’t take too long to find a free IP.\nI built an RPM with this patch for Fedora 20, you can download it from here, if you want to give it a try.\nAfter installing the patched Docker you should be able to run containers just like you’re used to:\ndocker run -i -t centos:latest /bin/bash Option 2: Manual address assignment Sometimes patching Docker is not an option.\nThis is where assigning IP addresses manually makes sense. Since Docker does not expose the ability to assign a selected IP directly to the docker run command — we need to do this in two steps:\nDisable the automatic network configuration in Docker by specifying -n=false,\nConfigure networking using the LXC configuration using -lxc-conf\nExample This is how it could be done:\ndocker run \\ -n=false \\ -lxc-conf=\u0026#34;lxc.network.type = veth\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.ipv4 = 172.16.42.20/24\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.ipv4.gateway = 172.16.42.1\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.link = docker0\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.name = eth0\u0026#34; \\ -lxc-conf=\u0026#34;lxc.network.flags = up\u0026#34; \\ -i -t centos:latest /bin/bash This will run a CentOS container with networking set up as follows:\nCreate a virtual ethernet interface\nAttach this interface to the docker0 bridge\nExpose it in the container as eth0\nAssign the 172.16.42.20 IP to the interface\nSet up the default gateway as 172.16.42.1\nIf you want to run multiple containers on one host, the only thing you’ll change is the IP address — everything else can be left as-is.\nExpected result If you followed the tutorial (no matter which option you choose) — you should be able to run containers on both hosts. Containers should be attached to the same network and be able to ping each other. Additionaly no IP address conflicts should happen.\nWin!\nTroubleshooting If you encounter some problems — you need to check the configuration.\nMake sure the brctl show command outputs similar content: bridge name bridge id STP enabled interfaces docker0 8000.7a7c5f332842 no br0 Make sure the ovs-vsctl show command outputs similar content: 73f7bcaa-7141-4b20-8fa8-3a0c1ec34f39 Bridge \u0026#34;br0\u0026#34; Port \u0026#34;br0\u0026#34; Interface \u0026#34;br0\u0026#34; type: internal Port \u0026#34;gre0\u0026#34; Interface \u0026#34;gre0\u0026#34; type: gre options: {remote_ip=\u0026#34;192.168.122.43\u0026#34;} ovs_version: \u0026#34;2.0.0\u0026#34; Make sure you can ping host1 from host2 and vice-versa. Make sure you can ping the docker0 interface running on host1 from host2 and vice-versa. Conclusion It’s possible to run Docker containers on different hosts that share the same network.\nIt’s even pretty simple. But like always — it could be better: Docker should make it possible without any workarounds.\nOne idea would be to implement the ARP requests directly in Go and drop the use of arping.\nThe other idea is to expose the network settings for the containers to the docker run call. I’m thinking here about the -i (IP with network prefix) and -g (gateway) options forwarded to dockerinit when launching a container.\nWhoah, you’re still reading this? Not bad.\nThanks!\n","permalink":"https://goldmann.pl/blog/2014/01/21/connecting-docker-containers-on-multiple-hosts/","summary":"\u003cblockquote class=\"alert alert-warning\"\u003e\n  \u003cp class=\"alert-heading\"\u003eWarning\u003c/p\u003e\n  \u003cp\u003eThis guide is based on an old version of Docker. The instructions you\nfind below may be already removed or changed in the Docker codebase.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eIn my \u003ca href=\"/blog/2014/01/16/running-fedora-cloud-images-on-kvm/\"\u003eprevious blog\npost\u003c/a\u003e I talked about running the\n\u003ca href=\"http://fedoraproject.org/en/get-fedora#clouds\"\u003eFedora Cloud images\u003c/a\u003e on\na local KVM with libvirt. This was not a standalone task, but rather the preparation\nfor this blog post: running \u003ca href=\"http://www.docker.io/\"\u003eDocker\u003c/a\u003e\ncontainers on multiple hosts \u003cstrong\u003eattached to the same network\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eI was asked in the comments on my\n\u003ca href=\"/2013/10/07/wildfly-cluster-using-docker-on-fedora/\"\u003eWildFly cluster based\non Docker blog post\u003c/a\u003e if it would be possible to run a cluster on multiple\nhosts. I found a\n\u003ca href=\"http://fbevmware.blogspot.com/2013/12/coupling-docker-and-open-vswitch.html\"\u003every\nnice tutorial\u003c/a\u003e written by Franck Besnard. I’ve decided to set up a similar\nenvironment on my own to see how/if it works.\u003c/p\u003e","title":"Connecting Docker containers on multiple hosts"},{"content":"Inspired by Matt’s blog post I’ve decided to make something that is similar but better fits my use case. I plan to do some clustering and routing testing and therefore I need to have similar VMs running side-by-side. These images will be short-lived and I would like to automate as many things I can.\nAdditionally, I found out that the images shipped by Fedora require some changes to work well in my case, for example the default 2GB disk is too small.\nScript You can see my script here.\nMy script does create a new domain with the desired name with the cloud disk image. I use the a QCOW2 image to not eat all the free space on my SSD. The disk can be optionally grown to the desired size. The whole install is done without VNC using the text method. The domain is optionally run after the setup completes.\nI use the cloud-init script only for the initial setup (setting the password) - afterwards it is removed from the image. The same thing happens to the ISO used for the cloud-init configuration - it’s ejected and removed from the disk afterwards.\nSample run $ virt-install-fedora host Thu, 16 Jan 2014 14:28:58 +0100 Destroying the host1 domain... Thu, 16 Jan 2014 14:28:59 +0100 Generating ISO for cloud-init... Thu, 16 Jan 2014 14:28:59 +0100 Installing the domain and adjusting the configuration... Thu, 16 Jan 2014 14:29:23 +0100 Cleaning up cloud-init... Thu, 16 Jan 2014 14:29:23 +0100 Resizing the disk... Thu, 16 Jan 2014 14:30:15 +0100 Launching the host1 domain... Thu, 16 Jan 2014 14:30:15 +0100 DONE, ssh to the 192.168.122.43 host using \u0026#39;fedora\u0026#39; username and \u0026#39;fedora\u0026#39; password After about a minute I have a registered domain with a Fedora 20 disk image on a 20GB QCOW2 disk. Pretty good. And I can run the command as many times I want to deploy new VMs.\nAlong with the disk image — the script creates a log file (in my case host1/host1.log) in which you can see the messages from the commands that were run during the installation.\n","permalink":"https://goldmann.pl/blog/2014/01/16/running-fedora-cloud-images-on-kvm/","summary":"\u003cp\u003eInspired by\n\u003ca href=\"http://spinningmatt.wordpress.com/2014/01/08/a-recipe-for-starting-cloud-images-with-virt-install/\"\u003eMatt’s\nblog post\u003c/a\u003e I’ve decided to make something that is similar but better fits\nmy use case. I plan to do some clustering and routing testing and therefore I\nneed to have similar VMs running side-by-side. These images will be short-lived\nand I would like to automate as many things I can.\u003c/p\u003e\n\u003cp\u003eAdditionally, I found out that the images shipped by Fedora require some changes\nto work well in my case, for example the default 2GB disk is too small.\u003c/p\u003e","title":"Running Fedora Cloud images on KVM"},{"content":"I had a power mangement issue when running Fedora 19 (and later 20) on my Lenovo ThinkPad 430s. When the battery was low - the laptop just powered off itself, without a clean shutdown or even warning me. As you may guess - this wasn’t something I very happy about.\nCause I discovered that it happens when the battery is still at 15%. The system reported at that time still about 40 min of available time.\nBy default Fedora uses the time based policy for battery power management. In almost all cases this is a good choice, but this time it won’t fly.\nSolution Instead of fixing the issue properly (finding the source of wrong estimate or wrong battery reading) I found a workaround which works very well and does not involve any magic: I disabled the time based and switched to percentage based policy.\ngsettings set org.gnome.settings-daemon.plugins.power use-time-for-policy false The other thing we need to do is to adjust when the warning will apear and what type of action should be executed when the battery level is critical.\ngsettings set org.gnome.settings-daemon.plugins.power percentage-critical 25 gsettings set org.gnome.settings-daemon.plugins.power percentage-low 30 gsettings set org.gnome.settings-daemon.plugins.power percentage-action 20 gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action \u0026#39;suspend\u0026#39; The system will warn me when the battery level is at 30%, another warning will apear at 25% and the action will be executed at 20% of battery level. What action? I choose supend because in almost all cases I have apower plug somewhere nearby, so I just need to plug in and I can work again almost immediately.\nYou can check the values for all power management settings by using this command:\ngsettings list-recursively org.gnome.settings-daemon.plugins.power If you prefer graphical tools — you can use dconf-editor to edit these values. The gui additionally shows a description for each key and what values are available to set.\nUpdate 30.07.2014 The real reason for this issue was a bad firmware in the battery. Lenovo released a battery upgrade utility, but… only for Windows. For Linux users the only way is to replace the battery or ask a friend with Windows to do the upgrade for you. I choose the 2nd option :) On the support page page you can find a list of affected batteries.\n","permalink":"https://goldmann.pl/blog/2014/01/12/wrong-battery-estimate-in-fedora-on-lenovo-thinkpad-430s/","summary":"\u003cp\u003eI had a power mangement issue when running \u003cstrong\u003eFedora 19\u003c/strong\u003e (and later 20) on my\n\u003ca href=\"http://shop.lenovo.com/us/en/laptops/thinkpad/t-series/t430\"\u003eLenovo\nThinkPad 430s\u003c/a\u003e. When the battery was low - the laptop just powered off itself,\nwithout a clean shutdown or even warning me. As you may guess - this wasn’t\nsomething I very happy about.\u003c/p\u003e\n\u003ch2 id=\"cause\"\u003eCause\u003c/h2\u003e\n\u003cp\u003eI discovered that it happens when the battery is \u003cstrong\u003estill at 15%\u003c/strong\u003e. The system\nreported at that time still about \u003cstrong\u003e40 min\u003c/strong\u003e of available time.\u003c/p\u003e","title":"Wrong battery estimate in Fedora on Lenovo ThinkPad 430s"},{"content":"It has been a while since my last blog post about recent Docker changes in Fedora. We’ve done some significant work over the last three weeks. Now it’s time to wrap it up.\nDocker is available in the repositories Now you can enjoy Docker on your Fedora system by executing just one command:\nyum install docker-io If you’re on RHEL/CentOS you still need to enable epel-testing repository. This shouldn’t be necessary once the lxc package will be available in stable.\nyum install docker-io --enablerepo epel-testing We also created systemd (or init.d — for EPEL) scripts for you so you can easily manage the Docker service.\nTo make it all happen, in the last 3 weeks we have closed 19 bugs.\nIssues? Please report all issues regarding the docker-io package in Red Hat Bugzilla in the correct place:\nBugs in Fedora package.\nBugs in EPEL package.\nDocker Registry is packaged This is new: some time ago I opened a review request for the docker-registry package. It has been finished and I was able to submit an update yesterday. Today I’ve added support for EPEL 6 and submitted a new update.\nOver the next few hours the docker-registry package will be pushed to updates-testing (or epel-testing for EPEL) so you’ll be able to play with it.\nIn Fedora:\nyum install docker-registry --enablerepo updates-testing And EPEL:\nyum install docker-registry --enablerepo epel-testing Issues? And again, please report all issues in Red Hat Bugzilla in the correct place:\nBugs in Fedora package.\nBugs in EPEL package.\nWhat’s next The major packaging work is done. Now it is your turn — please install these packages, use them, and report all issues in the places mentioned above. We’ll make sure they are fixed.\n","permalink":"https://goldmann.pl/blog/2013/12/03/even-more-docker-fedora-news/","summary":"\u003cp\u003eIt has been a while since my \u003ca href=\"/blog/2013/11/08/recent-docker-changes-in-fedora/\"\u003elast blog post\nabout recent Docker changes in Fedora\u003c/a\u003e. We’ve done some significant work over the last three weeks.\nNow it’s time to wrap it up.\u003c/p\u003e\n\u003ch2 id=\"docker-is-available-in-the-repositories\"\u003eDocker is available in the repositories\u003c/h2\u003e\n\u003cp\u003eNow you can enjoy Docker on your Fedora system by executing\njust one command:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eyum install docker-io\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eIf you’re on RHEL/CentOS you still need to enable \u003ccode\u003eepel-testing\u003c/code\u003e repository. This shouldn’t be necessary once the \u003ccode\u003elxc\u003c/code\u003e package \u003ca href=\"https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11454\"\u003ewill be available in stable\u003c/a\u003e.\u003c/p\u003e","title":"Even more Docker - Fedora news"},{"content":"What and why I am always sad seeing all the potential damage done to your local system, just to set up your development environment. Every time you do almost the same thing, every time you mess your system up in almost the same way. It really doesn’t matter in which language you’re wrtiting and what frameworks you use but Java (and Maven) is a pretty good, uhm, example.\nA development environment is not only about IDE and JDK, in almost all cases we need to have an application server too. We set it up; our application works great on it, but when we deploy it to production we experience deployment issues. Some things changed: we have different JDK, different network interfaces and so on. Everything can affect your application.\nImagine now an environment which is exactly the same as your production.\nWelcome to Docker!\nDocker makes it easy to create snapshots of your container. This means that you can deploy your app, create a snapshot, push the image to a repository for deployment and launch it in production from there.\nI want to make this a series of blog posts about how we can leverage Docker in the Java (but not only) world to make the development more pleasant and expectable with every iteration polishing the setup.\nTL;DR; In this blog post I’ll focus on the application server deployment. It shows how to set-up an environment for developing Java applications for WildFly. It uses JBoss Developer Studio as the IDE and the application is deployed to the server runnning in a Docker container. Curious? Read on!\nPlease note that everything below is pretty rough, since it’s my first take on it. Any hints on making it more developer friendly are appreciated, just leave a note in the comments.\nPreparations First of all we need to get all the required stuff:\nJDK: You should have something on your system, if not: yum install java-devel should help. Or go to Oracle…\nDocker: You can use the docker-io package available in my repo if you’re running Fedora. Otherwise you can follow the installation instructions available on the Docker website.\nJBoss Developer Studio: It can be downloaded from the product page.\nWildFly: It’s required by the IDE to detect what server we’re using and to get all required libraries locally. We can download it from here. Please grab the 8.0.0.Beta1 version.\nNext steps assume you have everything installed and working.\nDocker image I created a Docker image with WildFly on it. The application server is configured to be ready to run, so we can manage it from the IDE and deploy our applications to it.\nThe image is avalable in the Docker goldmann/jbds-wildfly repository.\nPlease pull it. This will grab the latest version for you:\n$ docker pull goldmann/jbds-wildfly You can now try to run it to confirm that it works as expected:\n$ docker run -i -t goldmann/jbds-wildfly:wildfly The container is running. You can use your IDE now to deploy your apps. Great, it works. Now we can proceed to the IDE setup.\nNote\nYou can run the container in detached mode by using the -d switch. See the documentation of the run command for more info.\nJBoss Developer Studio Lets open JBDS and teach this thing to talk to the application server.\nAdding a new remote connection Note\nYou can skip this by importing the connection. Right click in the Remote Systems tab, select Import….\nIn the Remote Systems tab we need to create a new connection to the Docker container. Please select Linux from the list.\nIn the next step please leave the Host Name field with LOCALHOST entered. Last, specify the Connection Name, I choose Docker.\nNote\nThe prepared Docker image exports the following container ports: 22, 8080 and 9990 as local ports: 10022, 18080 and 19990.\nIn the Files step, select the ssh.files configuration. In the Processes step, select the processes.shell.linux configuration. In the Shells step, select the ssh.shells configuration. In the Ssh Terminals step, select the ssh.terminals configuration.\nAfter you create the connection, please right click on the Ssh Terminals and select Subsystems. On that page we need to change the port from 22 to 10022.\nNow we can try to connect to the container, right click on the connection and select Connect. You’ll be asked about password and user ID, please use root / verysecure.\nNote\nIf you select the Save password option you can be asked for creating/using the Secure Storage Password.\nA nice feature is the Ssh Terminal — you can launch one and execute commands directly inside the container. Try it!\nTroubleshooting If you hit any issues, please try following:\nPlease make sure your Docker container is running.\nCheck firewall. Docker container (at least on Fedora) are connected the docker0 interface.\nIf this doesn’t help — let me know in the comments, I’ll try to help.\nAdding a new server Please unpack the WildFly zip you downloaded.\nIn the Servers tab please add new new server. From the list of available server choose JBoss Community \u0026gt; WildFly 8.0 (Experimental), click Next.\nPlease change the Server’s host name field from localhost to 0.0.0.0. Because of the nature of the containers this will let us manage the server from IDE directly.\nIn the next step in the Home Directory field specify the directory to where you unpacked the WildFly zip content.\nIn the next step please check the Listen on all interfaces… and Expose your management checkboxes. We need to change the deployment from local to remote, please select Remote System Deployment from the dropdown.\nAfter finishing the host set up wizard select the newly created Docker host from dropdown.\nWe’re ready to set the Remote Server Home field. Click Browse and expand Root \u0026gt; / \u0026gt; usr / \u0026gt; share \u0026gt; wildfly.\nThe last thing is to change the server settings, double click on the newly created server.\nIn the Server Ports section please change the web port to 18080 and management port to 19990.\nIn the Management Login Credentials section fields please enter admin and Admin#70365 as credentials.\nYou can now try to start your server. See the Console tab for the output.\nOK, we have now a new server defined, which is running inside a container. Let’s prepare an application to make use of it!\nApplication JBoss’ developers provide a great set of examples for various technologies under the JBoss Developer Framework. There are many articles, videos and — most exciting — code.\nWe’ll use one example by creating a new project, select File \u0026gt; New \u0026gt; Example… \u0026gt; Project Examples. Feel free to select example what you want. I used the Web Applications \u0026gt; kitchensink one.\nJBDS will download all the required code and preapre it to run.\nThe last step is to add the application to the server. It’ll be automatically deployed and ready to check at http://localhost:18080/jboss-as-kitchensink.\nDone Please note the that you can stop the container, launch another one and still be able to develop your app!\nIf you get hit by a long deployment time, then most probably you see the JBIDE-12202 which will be fixed in the next version of JBDS.\n","permalink":"https://goldmann.pl/blog/2013/11/20/developing-with-wildfly-jboss-developer-studio-and-docker/","summary":"\u003ch2 id=\"what-and-why\"\u003eWhat and why\u003c/h2\u003e\n\u003cp\u003eI am always sad seeing all the potential damage done to your local system, just\nto set up your development environment. Every time you do almost the same thing,\nevery time you mess your system up in almost the same way. It really doesn’t matter\nin which language you’re wrtiting and what frameworks you use but \u003cstrong\u003eJava\u003c/strong\u003e (and Maven)\nis a pretty good, uhm, example.\u003c/p\u003e\n\u003cp\u003eA development environment is not only about IDE and JDK, in almost all cases we\nneed to have an application server too. We set it up; our application works\ngreat on it, but when we deploy it to production we experience deployment\nissues. Some things changed: we have different JDK, different network\ninterfaces and so on. \u003cstrong\u003eEverything\u003c/strong\u003e can affect your application.\u003c/p\u003e","title":"Developing with WildFly, JBoss Developer Studio and Docker"},{"content":"Lokesh, the docker-io package maintainer at Fedora, does a damn good job at keeping it up to date. I think it\u0026rsquo;s a good time to see what changed over the last weeks in the Docker-Fedora world.\nWhy Docker is still not available in Fedora? Simple answer There are some technical issues to overcome :)\nLonger answer The most important blocker is lack of AUFS support in the kernel (upstream as well as Fedora\u0026rsquo;s and RHEL\u0026rsquo;s). Alex Larsson is working on a replacement for AUFS using devicemapper. You can read more about this work in a nice blog post where Alex is covering this area.\nIf you\u0026rsquo;re interested in the actual code, please look at the dm branch in the official Docker GitHub repo.\nNot yet in the official repos At least not for Fedora 19 and 20. In Rawhide we do have a docker-io package avaialable, but Rawhide is intended for testing, and this is what we do now with the docker-io package. Additionally we agreed with upstream to not push Docker to Fedora repos before the 0.7.0 release. This is very closely related to Alex\u0026rsquo;s work on devicemapper. We do not want to make avialable half-backed solutions.\nPlease be patient.\nUpdated repoToday I've updated my repository. It contains the latest 0.7-0.13.dm version of docker-io package. But if you really want to get your hands dirty with the latest version - use my repository. You can of course help with testing and by reporting bugs you see, we appreciate it.\nOnly 64 bit This is not a Fedora choice, but it\u0026rsquo;s forced by upstream. Docker currently works only on 64 bit architectures, so there won\u0026rsquo;t be any build for other archs (including i386 and arm), at least for now. I\u0026rsquo;m not sure where the root of this problem lies, but I\u0026rsquo;ll do some research over then next few days.\nThis is a quite big issue, since it technically prevents us from adding Docker to Fedora, since all packages should be available on all supported architectures.\nI hope at that should is the key word here.\nChanges Some other important changes made from 0.6.3-2.devicemapper to 0.7-0.13.dm.\nNetworking issues when accessing servers from an instance are now resolved. Appropriate iptables rules are now created when starting the docker service.\nThe docker -v commands prints now correct version information.\nIf you\u0026rsquo;re using zsh - you have now completion enabled!\n","permalink":"https://goldmann.pl/blog/2013/11/08/recent-docker-changes-in-fedora/","summary":"\u003cp\u003eLokesh, the \u003ccode\u003edocker-io\u003c/code\u003e package maintainer at Fedora, does a damn good job at\nkeeping it up to date. I think it\u0026rsquo;s a good time to see what changed over the\nlast weeks in the Docker-Fedora world.\u003c/p\u003e\n\u003ch2 id=\"why-docker-is-still-not-available-in-fedora\"\u003eWhy Docker is still not available in Fedora?\u003c/h2\u003e\n\u003ch3 id=\"simple-answer\"\u003eSimple answer\u003c/h3\u003e\n\u003cp\u003eThere are some technical issues to overcome :)\u003c/p\u003e\n\u003ch3 id=\"longer-answer\"\u003eLonger answer\u003c/h3\u003e\n\u003cp\u003eThe most important blocker  is lack of \u003ca href=\"http://aufs.sourceforge.net/\"\u003eAUFS\u003c/a\u003e\nsupport in the kernel (upstream as well as Fedora\u0026rsquo;s and RHEL\u0026rsquo;s). Alex Larsson\nis working on a replacement for AUFS using devicemapper. You can read more\nabout this work in a nice \u003ca href=\"http://community.redhat.com/adventures-in-dockerland/\"\u003eblog\npost\u003c/a\u003e where Alex is\ncovering this area.\u003c/p\u003e","title":"Recent Docker changes in Fedora"},{"content":"In my previous blog post I introduced Docker and its Fedora integration. Now it\u0026rsquo;s time to do some serious (read: useful) stuff.\nA few years ago I started a project called CirrAS. It\u0026rsquo;s dead now, but the main idea behind it was to form a cluster of JBoss AS servers in the cloud, without any unnecessary steps. You just launched the instances, they found and connected to each other and the result was a working cluster. Additionally every cluster node registered itself in a front-end instance which worked as a load balancer and monitoring/management (we used RHQ) node.\nYou can still watch the screencast I created (over 3 years ago) to show how it works, but prepare for my Polish accent. You\u0026rsquo;ve been warned.\nSince that was a few years ago and we now have both WildFly (the JBoss AS successor) and Docker in Fedora, it\u0026rsquo;s time to use these new techonogies to do something similar.\nPreparations Pre-releasesBecause we're IT hipsters we need to use the latest technologies like Fedora 20 (pre-release), WildFly 8 (pre-release) and Docker (soon-to-be-in-Fedora). As you can imagine, bad things may happen. I assume you have Docker installed. If not, please refer to my previous blog post on how to do it on Fedora.\nDocker 0.6.3I've upgraded the Docker version available in my repo to 0.6.3. I\u0026rsquo;ve done some of the hard stuff for you already; I\u0026rsquo;ve prepared a very basic Fedora 20 image for Docker. Grab it with:\ndocker pull goldmann/f20 Now that you have my image locally, you can try to run it, like this:\n$ docker run -i -t goldmann/f20 /bin/bash bash-4.2# Building the basic WildFly image Now it\u0026rsquo;s time to extend the goldmann/f20 image and install the wildfly package on it. This can be easily done by using this Dockerfile:\n# Base on the Fedora image created by me FROM goldmann/f20 # Install WildFly RUN yum install -y wildfly Let\u0026rsquo;s build the image:\n$ docker build . Uploading context 10240 bytes Step 1 : FROM goldmann/f20 ---\u0026gt; 5c47c0892695 Step 2 : RUN yum install -y wildfly ---\u0026gt; Running in 984358fb5472 Resolving Dependencies --\u0026gt; Running transaction check ---\u0026gt; Package wildfly.noarch 0:8.0.0-0.9.Alpha4.fc20 will be installed --\u0026gt; Processing Dependency: java-devel \u0026gt;= 1:1.7 for package: wildfly-8.0.0-0.9.Alpha4.fc20.noarch [...SNIP...] xstream.noarch 0:1.3.1-8.fc20 xz-java.noarch 0:1.3-2.fc20 zip.x86_64 0:3.0-9.fc20 Complete! ---\u0026gt; a70a03698e7e Successfully built a70a03698e7e Time to test our image, let\u0026rsquo;s run the container and start WildFly:\n$ docker run -i -t a70a03698e7e /bin/bash bash-4.2# /usr/share/wildfly/bin/standalone.sh [...SNIP...] 09:25:55,305 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Alpha4 \u0026quot;WildFly\u0026quot; started in 2789ms - Started 161 of 196 services (57 services are lazy, passive or on-demand) Cool, it works!\nExtending the WildFly image Now that we have a working basic WildFly image, it\u0026rsquo;s time to make sure it works in a cluster too.\nWe\u0026rsquo;re going to create a standalone cluster. We won\u0026rsquo;t use the domain mode built into WildFly AS.\nThe Dockerfile Take a look at our Dockerfile. I\u0026rsquo;ll describe the important stuff later.\nIt is a good idea to create a custom launch script for WildFly. This will greatly simplify the Dockerfile for us. Our launch.sh file could look like this:\n#!/bin/bash IPADDR=$(ip a s | sed -ne '/127.0.0.1/!{s/^[ \\t]*inet[ \\t]*\\([0-9.]\\+\\)\\/.*$/\\1/p}') /usr/share/wildfly/bin/standalone.sh -c standalone-ha.xml -Djboss.bind.address=$IPADDR -Djboss.bind.address.management=$IPADDR -Djboss.node.name=server-$IPADDR And here is the Dockerfile itself:\n# Base on the Fedora image created by me FROM goldmann/f20 # Install WildFly RUN yum install -y wildfly # Create the management user RUN /usr/share/wildfly/bin/add-user.sh admin Admin#70365 --silent ADD launch.sh / RUN chmod +x /launch.sh # Run WildFly after the container boots ENTRYPOINT /launch.sh The first line tells docker that we want to use the goldmann/f20 image as our base. The second line installs the wildfly package with all the required dependencies (there are quite a few). Next, we create the admin user which will be used for node management. We also inject the launch.sh file and make it executable. This will be our entry point, meaning that this script will be executed after the container boots.\nBinding to the right address When you boot WildFly as we did previously it will bind to 127.0.0.1. This is not very useful since we\u0026rsquo;re launching an application server\u0026hellip; We need to bind it to the current IP address assigned to the NIC of the container. We can use the jboss.bind.address. To get the IP we can use some shell scripting. Please take a look at the launch.sh script above.\nWe do the same for the jboss.bind.address.management property which will be used later.\nClustering Our WildFly image uses the standalone.xml configuration file which is great, but not for the clustering purposes. Let\u0026rsquo;s switch to standalone-ha.xml. This will enable the clustering features.\nThe container network by default is multicast enabled. This is a great thing, since it allows WildFly\u0026rsquo;s auto discovery feature to work. Each node on the network will find and join the cluster automatically. Good stuff.\nPlease note that a node will search for clusters only when there is something deployed on it. When the application server is empty - it\u0026rsquo;ll register only in the front-end, without joining the cluster and setup session replication. This may be a bit misleading at first, since you\u0026rsquo;re expecting some messages in the logs right after starting a new node. Nope. You need to deploy an app first.\nApplication deployment We need to think about deploying apps to the cluster. There are various ways we can do it. I prefer to use the jboss-cli.sh script. To make it work, we need to expose the WildFly management interface. Which we\u0026rsquo;ve done already (remember the jboss.bind.address.management property?).\nThe last thing that prevents us from connecting to a running WildFly instance is the lack of a management user. Authentication is not required when you try to connect from localhost, but to connect to remote servers (our case) - we need to create a user. We can use the add-user.sh shell script, like this:\n/usr/share/wildfly/bin/add-user.sh admin Admin#70365 --silent Nope, this is not a very secure password, but will do for now.\nDone! You can now build the image with docker build . and you\u0026rsquo;re done!\nBuilding load balancer image OK, we have the back-end image providing WildFly, but to have a proper cluster we need a load balancer. Let\u0026rsquo;s create one with Apache HTTPD as the proxy. We chose HTTPD because of a very nice project called mod_cluster. The mod_cluster project consists of two parts:\nAn Apache HTTPD module, An application server component (shipped with WildFly, but available for other application servers too) This is different from the mod_proxy setup, since the back-end registers itself in the proxy, not the other way around. This is very valuable since we\u0026rsquo;re going to start and shut down nodes depending on the load, but the load balancer will stay online forever (hopefully).\nAnother nice thing is that if you have multicast enabled (which we do!) we can use the mod_advertise module. This will make load balancer recognition very easy. The load balancer will notify back-ends of its existence. When the back-end receives this information, it will automatically register itself with the front-end, knowing it\u0026rsquo;s location.\nCluster out-of-the-box? Yep, this is it.\nEnough talking, let\u0026rsquo;s create the load-balancer image.\n# Base on the Fedora image created by me FROM goldmann/f20 # Install Apache and mod_cluster RUN yum install -y httpd mod_cluster # Disable mod_proxy_balancer module to allow mod_cluster to work RUN sed -i 's|LoadModule proxy_balancer_module|# LoadModule proxy_balancer_module|' /etc/httpd/conf.modules.d/00-proxy.conf ADD launch.sh / ADD mod_cluster.conf /etc/httpd/conf.d/mod_cluster.conf RUN chmod +x /launch.sh # Do the required modifications and launch Apache after boot ENTRYPOINT /launch.sh The Dockerfile is simple. so I won\u0026rsquo;t describe it in detail. Instead I\u0026rsquo;ll focus on the mod_cluster.conf and launch.sh injected into the image:\nThe mod_cluster.conf will overwrite the default config file installed with the mod_cluster package. It will enable the advertise and mod_cluster manager features, the latter of which exposes a simple web interface allowing us to see all nodes connected to the cluster.\nLoadModule slotmem_module modules/mod_slotmem.so LoadModule proxy_cluster_module modules/mod_proxy_cluster.so LoadModule advertise_module modules/mod_advertise.so LoadModule manager_module modules/mod_manager.so MemManagerFile /var/cache/httpd ServerName *:80 \u0026lt;VirtualHost *:80\u0026gt; EnableMCPMReceive true ServerAdvertise On ServerName loadbalancer \u0026lt;Location /\u0026gt; Require all granted \u0026lt;/Location\u0026gt; \u0026lt;Location /mod_cluster_manager\u0026gt; SetHandler mod_cluster-manager Require all granted \u0026lt;/Location\u0026gt; \u0026lt;/VirtualHost\u0026gt; Just like with the back-end, we inject a launch.sh script:\n#/bin/bash # Get the IP address IPADDR=$(ip a s | sed -ne '/127.0.0.1/!{s/^[ \\t]*inet[ \\t]*\\([0-9.]\\+\\)\\/.*$/\\1/p}') # Adjust the IP addresses in the mod_cluster.conf file sed -i \u0026quot;s|[0-9\\.\\*]*:80|$IPADDR:80|g\u0026quot; /etc/httpd/conf.d/mod_cluster.conf # Run Apache httpd -D FOREGROUND The only thing we do here is adjust the IP addresses in the mod_cluster.conf file. This will ensure we send the correct IP address to the back-end nodes using the advertise feature.\nYou can now build this image.\nPrebuilt Images If you don\u0026rsquo;t want to take the time to build the images yourself, you can use the images I\u0026rsquo;ve pushed to the Docker repository. To grab them, just pull the goldmann/wildfly-cluster repo:\ndocker pull goldmann/wildfly-cluster This will take some time, since these images are quite big. In the end, you\u0026rsquo;ll have three images with the following tags: front-end, back-end and back-end-base.\nTesting Once you\u0026rsquo;ve built (or pulled) the images, we can begin to test them. Let\u0026rsquo;s start with the front-end image:\ndocker run -d -p 80:80 goldmann/wildfly-cluster:front-end This will start a front-end container in detached mode. As a bonus we\u0026rsquo;re redirecting port 80 from the host directly to this container making the Apache running in the container available directly via the host IP.\nIf you go now to the host IP address using your browser, you should be see the Apache HTTPD test page. If you point your browser at /mod_cluster_manager, you should see a mod_cluster manager page without any nodes.\nLet\u0026rsquo;s add some back-end nodes. Run this twice:\ndocker run -d goldmann/wildfly-cluster:back-end Wait a few seconds, and refresh the browser. You should now see two nodes.\nYour cluster is working, congrats!\nDeploying applications We prepared the back-end nodes for management by creating the management user before. Now it\u0026rsquo;s time to use this user to deploy an application. You\u0026rsquo;ll need the jboss-cli.sh script shipped with WildFly. You can get it by downloading WildFly or installing it (for exmaple using yum install wildfly, if you\u0026rsquo;re on Fedora 20+).\nWe need the IP address of the node we want to connect to. You can use the docker inspect command, looking for the IPAddress.\nNext we need to connect to (use port 9990) and authenticate with (use admin/Admin#70365 credentails) the node:\n$ $WILDFLY_HOME/bin/jboss-cli.sh WARN: can't find jboss-cli.xml. Using default configuration values. You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect 172.17.0.2:9990 Authenticating against security realm: ManagementRealm Username: admin Password: [standalone@172.17.0.2:9990 /] deploy your-app.war The CLI provides you many useful (and powerful) features. From deploying to managing the whole server. You can learn more about it in the documentation.\nOnce you deploy your web app, you\u0026rsquo;ll see the context avaiable in the mod_cluster manager.\nDeploying to all of nodesTo deploy the application on every node in the cluster (in standalone mode) you need to repeat the above step for all nodes in the cluster. Of course there are other options, but this is not part of the tutorial. The last thing left is to point your browser at the front-end IP and the context of your app. It should be available and running. If you deploy your app on multiple nodes requests will be routed to all back-ends, as you would expect. Try it out!\nSummary It\u0026rsquo;s really easy to create a cluster for your Java EE applications using Docker and Fedora. Because of the nice Docker/LXC features, we\u0026rsquo;re now able to grow the cluster in literally seconds.\nOnce again: everything shown here is based on pre-releases. The Fedora/WildFly/Docker integration will be improved over time, but give it a shot today and let me know how you like it. If you find a bug, please report it directly in Bugzilla or ping me in the #fedora-cloud or #fedora-java IRC channels.\n","permalink":"https://goldmann.pl/blog/2013/10/07/wildfly-cluster-using-docker-on-fedora/","summary":"\u003cp\u003eIn my \u003ca href=\"/blog//2013/09/25/docker-and-fedora/\"\u003eprevious blog post\u003c/a\u003e I introduced\n\u003ca href=\"https://www.docker.io/\"\u003eDocker\u003c/a\u003e and its \u003ca href=\"http://fedoraproject.org/\"\u003eFedora\u003c/a\u003e\nintegration. Now it\u0026rsquo;s time to do some serious (read: useful) stuff.\u003c/p\u003e\n\u003cp\u003eA few years ago I started a project called CirrAS. It\u0026rsquo;s dead now, but the main\nidea behind it was to form a cluster of \u003ca href=\"https://www.jboss.org/jbossas\"\u003eJBoss\nAS\u003c/a\u003e servers in the \u003cem\u003ecloud\u003c/em\u003e, without any\nunnecessary steps. You just launched the instances, they found and connected to\neach other and the result was a \u003cstrong\u003eworking cluster\u003c/strong\u003e. Additionally every cluster\nnode registered itself in a front-end instance which worked as a load balancer\nand monitoring/management (we used \u003ca href=\"http://www.jboss.org/rhq\"\u003eRHQ\u003c/a\u003e) node.\u003c/p\u003e","title":"WildFly cluster using Docker on Fedora"},{"content":" For the last couple of days I have been playing with Docker. Docker is a project that helps you create images and run containers. This sounds like virtualization, but it isn\u0026rsquo;t. It uses Linux Containers (LXC) under the hood to do all the magic. What kind of magic? Read on.\nLinux Containers The first question you might ask is: how is Docker/LXC different from virtualization?\nLXC is something between chroot and full virtualization. You don\u0026rsquo;t run your applications in a virtual machine (inside a process controlled by the virtualization engine). Instead your applications are run in isolated (by the kernel itself) environments. Processes that run in one container do not have any access to processes in other containers. From a cointainer POV it looks like virtualization, but when you look from the host side - you can see all of the processes (applications) running on the host, directly. I\u0026rsquo;m pretty new to the LXC technology, but it\u0026rsquo;s very promising, especially with regards to speed.\nThe most visible difference between virtualization and LXC for the end user is boot time. LXC overhead is literally zero compared to the few seconds up to minutes to boot your operating system in a virtualized environment. When you run a container, it\u0026rsquo;s ready to do the stuff immediately - you don\u0026rsquo;t need to wait at all.\nThis single feature is a great reason to take a look at LXC. But there is also Docker, which is a great extension of what we already have in LXC.\nHello Docker Docker builds upon LXC. It uses it to create images and later run and manage them. What makes Docker especially nice is its lightweight and easy to use. The good folks at Docker made Ubuntu their distribution of choice, but Fedora isn\u0026rsquo;t sleeping. Just recently Lokesh Mandvekar created a docker-io package and it was reviewed and accepted for Fedora. It\u0026rsquo;ll take a week or two for it become available in the Fedora 19+ repos. If you\u0026rsquo;re eager (and brave) - I prepared my own Docker repository with RPMs for Fedora 19, 20 and Rawhide. This repo will become unavailable after the official Docker RPMs hit Fedora repos.\nFedora 20 hostPlease note that I used a Fedora 20 host, but it should work on Fedora 19 too. Superuser privilegesAll commands below should be executed with root privileges. curl http://goldmann.fedorapeople.org/repos/docker.repo \u0026gt; /etc/yum.repos.d/docker-goldmann.repo yum install docker-io When the install finishes - start the docker systemd service:\nsystemctl start docker.service And if you want to enable it on boot:\nsystemctl enable docker.service Docker should be running now.\nRun your first container Docker offers a central repository with images. This makes it easy to download (and publish) images. Matthew Miller (Fedora Cloud Architect) prepared a Fedora 19 image. This image will be updated to Fedora 20 once it is released.\nLet\u0026rsquo;s grab the fedora image:\n$ docker pull mattdm/fedora Pulling repository mattdm/fedora 22a514a5aa4c: Download complete 50f374c05c2c: Download complete 97fc5bf7f8d4: Download complete Done! Now you have the image locally (in /var/lib/docker) and you can immediately start a container based on it:\ndocker run -i -t mattdm/fedora /bin/bash Let\u0026rsquo;s look at the parameters:\nrun - runs a container, -i - keeps the stdin open, even if there is nothing attached, -t - allocates a pseudo terminal, so we can interact with the container directly, mattdm/fedora - ID of the image, it can be a tag or a hash (22a514a5aa4c in this case), /bin/bash - the command to run after the container boots. After you run the command, you\u0026rsquo;ll be greeted by the bash prompt from inside the container, where you can do whatever you want. There are different types of images, some of them have an entry point, some not. I hope to discuss this further in a different blog post.\n$ docker run -i -t mattdm/fedora /bin/bash bash-4.2# If you see an error similar to this, try again.\n2013/09/25 13:22:02 Error: Error starting container 4b9cdcc43f43: fork/exec /usr/bin/unshare: operation not permitted This is a known bug and I hope it will be fixed soon.\nBasic container management To stop the container, just press CTRL+D. Please note that the container is now stopped, but that does not mean that it no longer exists. Stopped container can be started or removed.\nTo remove a stopped container you need to know the container ID. You can see it by using the docker ps command. By default the docker ps command will show only running containers. To see all containers (including stopped) run docker ps -a:\n$ docker ps -a ID IMAGE COMMAND CREATED STATUS PORTS 15bd697c7174 mattdm/fedora:latest /bin/bash 22 minutes ago Exit 0 5ab7c7a95885 mattdm/fedora:latest /bin/bash 23 minutes ago Exit 0 4b9cdcc43f43 mattdm/fedora:latest /bin/bash 23 minutes ago Exit 0 0fdab01e4eaa mattdm/fedora:latest /bin/bash 24 minutes ago Exit 0 Now you can remove the container by executing the docker rm command and specifying the ID, for example docker rm 15bd697c7174. The 15bd697c7174 container is now gone.\nNetwork connectivity By default Fedora disables IP forwarding which will prevent you from accessing the Internet from inside of the container. In most (all?) cases this is not what you want. To enable IP forwarding you can run this command:\nsysctl -w net.ipv4.ip_forward=1 After restarting, forwarding will be disabled again. To make it persistent, create a /etc/sysctl.d/80-docker.conf file and put the following line in it:\nnet.ipv4.ip_forward = 1 There is an open bug to fix this in Fedora.\nBuild your first image What we have done so far is run an image made by someone else. Let\u0026rsquo;s create our own image now.\nDocker uses plain text files to describe the image which can contain various commands. To build an image, let\u0026rsquo;s create an empty directory and place a file in it called Dockerfile with following content:\n# Base on the Fedora image created by Matthew FROM mattdm/fedora # Install the JBoss Application Server 7 RUN yum install -y jboss-as # Run the JBoss AS after the container boots ENTRYPOINT /usr/share/jboss-as/bin/launch.sh standalone standalone.xml 0.0.0.0 The FROM command is required and tells Docker which image should be used as a base for our new image.\nThe RUN command is used to modify the image by running a command inside the container at the time of building it.\nThe ENTRYPOINT command specifies which command should be executed after the container fully boots.\nThe next step is to build the image itself. In the directory execute the docker build . command:\n$ docker build . Uploading context 10240 bytes Step 1 : FROM mattdm/fedora ---\u0026gt; 22a514a5aa4c Step 2 : RUN yum install -y jboss-as ---\u0026gt; Running in 4e4d90823207 Resolving Dependencies --\u0026gt; Running transaction check ---\u0026gt; Package jboss-as.noarch 0:7.1.1-21.fc19 will be installed --\u0026gt; Processing Dependency: wss4j \u0026gt;= 1.6.7 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: wsdl4j \u0026gt;= 1.6.2-5 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: resteasy \u0026gt;= 2.3.2-7 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: mod_cluster-java \u0026gt;= 1.2.1-2 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: jython \u0026gt;= 2.2.1-9 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: jbossws-spi \u0026gt;= 2.1.0 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: jbossws-native \u0026gt;= 4.1.0 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: jbossws-cxf \u0026gt;= 4.1.0 for package: jboss-as-7.1.1-21.fc19.noarch --\u0026gt; Processing Dependency: jbossws-common \u0026gt;= 2.0.4-3 for package: jboss-as-7.1.1-21.fc19.noarch [....SNIP...] xpp3.noarch 0:1.1.3.8-8.fc19 xpp3-minimal.noarch 0:1.1.3.8-8.fc19 xsom.noarch 0:0-9.20110809svn.fc19 xstream.noarch 0:1.3.1-5.fc19 zip.x86_64 0:3.0-7.fc19 Complete! ---\u0026gt; fafccbe2bffc Step 3 : ENTRYPOINT /usr/share/jboss-as/bin/launch.sh standalone standalone.xml 0.0.0.0 ---\u0026gt; Running in 055d264ab953 ---\u0026gt; 366ff524eea0 Successfully built 366ff524eea0 Please note that after every command Docker commits the changes (in a manner similar to Git). Future executions of the same command will use the cached result.\nNow if we run docker run -i -t 366ff524eea0 (please note that we don\u0026rsquo;t specify the /bin/bash command, since our image has an entry point and it will be executed for us) we\u0026rsquo;ll see JBoss AS booting:\n$ docker run -i -t 366ff524eea0 ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /usr/share/jboss-as JAVA: java [...SNIP...] 13:28:15,433 WARN [org.jboss.as.domain.http.api] (MSC service thread 1-4) JBAS015102: Unable to load console module for slot main, disabling console 13:28:15,442 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory /usr/share/jboss-as/standalone/deployments 13:28:15,520 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS] 13:28:15,552 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990 13:28:15,553 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final \u0026quot;Brontes\u0026quot; started in 2328ms - Started 133 of 208 services (74 services are passive or on-demand) That\u0026rsquo;s it, JBoss AS is running.\nWhat\u0026rsquo;s next I highly recommend the try-and-fail method. Read the Docker docs, try to build your own images. In future blog posts I\u0026rsquo;ll get a bit more into Docker details (and we\u0026rsquo;ll build a cluster).\nHope you enjoyed this quick ride with Docker and Fedora!\n","permalink":"https://goldmann.pl/blog/2013/09/25/docker-and-fedora/","summary":"\u003cimg style=\"padding: 5px; float: left; margin-right: 10px; width: 30%;\" alt=\"WildFly\" src=\"/images/docker.png\" /\u003e\n\u003cp\u003eFor the last couple of days I have been playing with\n\u003ca href=\"https://www.docker.io/\"\u003eDocker\u003c/a\u003e. Docker is a project that helps you create\nimages and run containers. This sounds like virtualization, but it\nisn\u0026rsquo;t. It uses \u003ca href=\"http://lxc.sourceforge.net/\"\u003eLinux Containers\u003c/a\u003e (LXC) under the\nhood to do all the magic. What kind of magic? Read on.\u003c/p\u003e\n\u003ch3 id=\"linux-containers\"\u003eLinux Containers\u003c/h3\u003e\n\u003cp\u003eThe first question you might ask is: \u003cem\u003ehow is Docker/LXC different from virtualization?\u003c/em\u003e\u003c/p\u003e","title":"Docker and Fedora"},{"content":"In April 2013 the JBoss Application Server rename to WildFly was announced at Devoxx. Since then the WildFly team made a couple of Alpha releases. They all start with version 8.0.0 to highlight the fact that WildFly is the successor of JBoss AS.\nImmediately after the first release of WildFly I\u0026rsquo;ve started to think about getting it into Fedora.\nA few days ago I finished upgrading all required components and finally packaged Alpha3 version of WildFly. It\u0026rsquo;s already available in Rawhide and in Fedora 20 updates-testing repository.\nChanges As you can imagine the name change triggered some changes to the Fedora jboss-as package. The most visible one is the package rename. In Fedora 20+ the jboss-as package is replaced with wildfly. Other than dependencies upgrade and some scripts name changes nothing was dramatically changed - you can still expect thing to work as you\u0026rsquo;re used to.\nIf you hit any issues - please let me know!\nOf course WildFly is a brand new application server with some new great features like Java EE 7 support, so do not forget to test your new apps on it!\nToday I submitted a new update for Fedora 20 that includes the Alpha4 version. It fixes also a few bugs reported to me (thanks!). I personally feel that this update is pretty stable. Give it a shot and don\u0026rsquo;t forget to bump the karma!\nThe future The plan is simple - package the most recent version of WildFly and make it available in the shortest period of time after the upstream release. With the Fedora 20 Final release approaching (planned 2013.11.19) - I\u0026rsquo;m going to make everything possible to package 8.0.0.Final before so Fedora 20 can ship stable version of WildFly since the beginning. This will be a very tough task since the release dates are very close to each other. If not - the 8.0.0.Final will be a 0-day update.\n","permalink":"https://goldmann.pl/blog/2013/09/18/wildfly-is-approaching-fedora/","summary":"\u003cp\u003eIn April 2013 the \u003ca href=\"https://community.jboss.org/blogs/mark.little/2013/04/19/and-the-winner-is\"\u003eJBoss Application Server rename to\nWildFly\u003c/a\u003e\nwas announced at Devoxx. Since then the \u003ca href=\"http://wildfly.org/\"\u003eWildFly\u003c/a\u003e team\nmade a couple of Alpha releases. They all start with version \u003ccode\u003e8.0.0\u003c/code\u003e to\nhighlight the fact that WildFly is the successor of JBoss AS.\u003c/p\u003e\n\u003cimg style=\"padding: 5px; float: left; margin-right: 10px; width: 60%;\" alt=\"WildFly\" src=\"/images/wildfly.png\" /\u003e\n\u003cp\u003eImmediately after the first release of WildFly I\u0026rsquo;ve started to think about\ngetting it into \u003ca href=\"http://fedoraproject.org/\"\u003eFedora\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eA few days ago I finished upgrading all required components and finally\npackaged \u003ccode\u003eAlpha3\u003c/code\u003e version of WildFly. It\u0026rsquo;s already available in Rawhide and in\n\u003ca href=\"https://admin.fedoraproject.org/updates/FEDORA-2013-16408\"\u003eFedora 20\nupdates-testing\u003c/a\u003e\nrepository.\u003c/p\u003e","title":"WildFly is approaching Fedora"},{"content":"JBoss Application Server shipped in Fedora makes it easy to run it as a system service. So far you could launch only the standalone mode, there was no easy way to run it in the domain mode. This is going to change.\nIf you\u0026rsquo;re not familiar with the operating modes, I highly recommend you reading the introduction to it. In short, in domain mode you can launch more than one server on one host easily. But this is not everything – you get a single entry point for management for all these instances. This means that you can deploy applications one all instances by just executing one command!\nAvailable with the next jboss-as package updateDomain mode will be available with the next jboss-as package update 7.1.1-19 on Fedora 19+. Configuration With the jboss-as-7.1.1-19 update you\u0026rsquo;ll be able to select which mode should be used when running the systemd service for JBoss AS. To do this you need to edit the /etc/jboss-as/jboss-as.conf file.\nYou can choose the mode by setting the JBOSS_MODE environment variable. Do not forget to select a valid configuration file by setting the JBOSS_CONFIG variable.\n# The configuration you want to run # # JBOSS_CONFIG=standalone.xml JBOSS_CONFIG=domain.xml # The mode you want to run # JBOSS_MODE=standalone JBOSS_MODE=domain # The address to bind to # JBOSS_BIND=0.0.0.0 Afterwards you can restart the server by simply using the systemctl command:\n$ systemctl restart jboss-as.service And voila – domain mode is running with two JBoss AS instances (default case):\n$ systemctl status jboss-as.service jboss-as.service - The JBoss Application Server Loaded: loaded (/usr/lib/systemd/system/jboss-as.service; disabled) Active: active (running) since pią 2013-05-24 10:56:30 CEST; 7s ago Main PID: 1325 (launch.sh) CGroup: name=systemd:/system/jboss-as.service ├─1325 /bin/sh /usr/share/jboss-as/bin/launch.sh domain domain.xml 0.0.0.0 ├─1326 /bin/sh /usr/share/jboss-as/bin/domain.sh -c domain.xml -b 0.0.0.0 ├─1368 java -D[Process Controller] -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byt... ├─1382 java -D[Host Controller] -Dorg.jboss.boot.log.file=/usr/share/jboss-as/domain/log/host-controller.log -Dlogging.configuration=file:/usr/share/jboss-as/domain/configuration/logging.properties -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Sta... ├─1433 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64/jre/bin/java -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms64m -Xmx512m -server -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -Dsun... └─1451 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64/jre/bin/java -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms64m -Xmx512m -server -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -Dsun... Domain management examples The JBoss AS domain is so powerful that you can launch another server instance by using just the CLI:\n[domain@localhost:9999 /] /host=master/server-config=server-three:start { \u0026quot;outcome\u0026quot; =\u0026gt; \u0026quot;success\u0026quot;, \u0026quot;result\u0026quot; =\u0026gt; \u0026quot;STARTING\u0026quot; } [domain@localhost:9999 /] /host=master/server-config=server-three:read-resource(include-runtime=true) { \u0026quot;outcome\u0026quot; =\u0026gt; \u0026quot;success\u0026quot;, \u0026quot;result\u0026quot; =\u0026gt; { \u0026quot;auto-start\u0026quot; =\u0026gt; false, \u0026quot;group\u0026quot; =\u0026gt; \u0026quot;other-server-group\u0026quot;, \u0026quot;interface\u0026quot; =\u0026gt; undefined, \u0026quot;jvm\u0026quot; =\u0026gt; undefined, \u0026quot;name\u0026quot; =\u0026gt; \u0026quot;server-three\u0026quot;, \u0026quot;path\u0026quot; =\u0026gt; undefined, \u0026quot;socket-binding-group\u0026quot; =\u0026gt; undefined, \u0026quot;socket-binding-port-offset\u0026quot; =\u0026gt; 250, \u0026quot;status\u0026quot; =\u0026gt; \u0026quot;STARTED\u0026quot;, \u0026quot;system-property\u0026quot; =\u0026gt; undefined } } You can check the status of the service to confirm that the server is actually a new instance:\n$ systemctl status jboss-as.service jboss-as.service - The JBoss Application Server Loaded: loaded (/usr/lib/systemd/system/jboss-as.service; disabled) Active: active (running) since pią 2013-05-24 10:56:30 CEST; 8min ago Main PID: 1325 (launch.sh) CGroup: name=systemd:/system/jboss-as.service ├─1325 /bin/sh /usr/share/jboss-as/bin/launch.sh domain domain.xml 0.0.0.0 ├─1326 /bin/sh /usr/share/jboss-as/bin/domain.sh -c domain.xml -b 0.0.0.0 ├─1368 java -D[Process Controller] -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byt... ├─1382 java -D[Host Controller] -Dorg.jboss.boot.log.file=/usr/share/jboss-as/domain/log/host-controller.log -Dlogging.configuration=file:/usr/share/jboss-as/domain/configuration/logging.properties -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Sta... ├─1433 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64/jre/bin/java -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms64m -Xmx512m -server -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -Dsun... ├─1954 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64/jre/bin/java -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms64m -Xmx512m -server -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -Dsun... └─2076 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64/jre/bin/java -D[Server:server-three] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms64m -Xmx512m -server -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -Ds... Now you can use the JBoss AS CLI to deploy application to all running instances in one step:\n[domain@localhost:9999 /] deploy node-info.war --all-server-groups Nice, isn\u0026rsquo;t?\nOf course there is more stuff you can do with it, please read the documentation.\nThe update was submitted to Fedora 19 and is already available in Rawhide. Please give it a shot and add some karma!\nUpdate 28.05.2013 Please make sure you install the jacorb-2.3.1-5 bugfix update available now in updates-testing repository. This fixes some issues when running JBoss AS in high-availability and in domain mode.\n","permalink":"https://goldmann.pl/blog/2013/05/24/domain-mode-in-fedoras-jboss-as/","summary":"\u003cp\u003e\u003ca href=\"http://www.jboss.org/jbossas\"\u003eJBoss Application Server\u003c/a\u003e shipped in\n\u003ca href=\"https://fedoraproject.org/\"\u003eFedora\u003c/a\u003e makes it easy to run it as a system\nservice. So far you could launch only the \u003ccode\u003estandalone\u003c/code\u003e mode, there was no easy\nway to run it in the \u003ccode\u003edomain\u003c/code\u003e mode. This is going to change.\u003c/p\u003e\n\u003cp\u003eIf you\u0026rsquo;re not familiar with the operating modes, I highly recommend you reading\nthe \u003ca href=\"https://docs.jboss.org/author/display/AS71/Operating+modes\"\u003eintroduction to\nit\u003c/a\u003e. In short, in\ndomain mode you can launch more than one server on one host easily. But this\nis not everything – you get a single entry point for management for all\nthese instances. This means that you can deploy applications one all instances\nby just executing one command!\u003c/p\u003e","title":"Domain mode in Fedora's JBoss AS"},{"content":"I haven\u0026rsquo;t been giving talks lately. There were various reasons for it; but the most important is that I was busy with the Fedora/JBoss AS stuff for quite some time. The good (?) news is that I\u0026rsquo;m back to real programming. Since a couple of months I\u0026rsquo;m helping with TorqueBox, expecially in the messaging space. This is a great opportunity to share this cool stuff with people.\nI\u0026rsquo;ve decided to submit my first ever talk to GeeCON and it was accepted, yay! I know the conference pretty well and I enjoy it every time I\u0026rsquo;m attending. This is also true to the OpenSpaces co-event which is held the day after the main conference (this year it\u0026rsquo;s 18th May). For more information about the conference please reach out to the conference page.\nI\u0026rsquo;m giving a talk titled Messaging and scheduled jobs made simple about messaging features of TorqueBox on the first day (Wed, May 15), at 11:40am.\nWhat can you expect?\nReally quick introduction to TorqueBox (nope, I\u0026rsquo;m not going to discuss all its features) Java Message Service concepts refresh Messaging features explained with a demo for each feature showing how to use it Introduction to scheduled jobs (with demo too!) Hope to see you at GeeCON!\nUpdate 21.05.2013 Thanks for attending my talk!\nIf you missed the presentation, don\u0026rsquo;t worry! Slides are available here for you. If you\u0026rsquo;re interested in the demos - you can grab them from this repository.\n","permalink":"https://goldmann.pl/blog/2013/05/09/geecon-2013/","summary":"\u003cp\u003eI haven\u0026rsquo;t been giving talks lately. There were various reasons for it; but the most\nimportant is that I was busy with the \u003ca\nhref=\"https://fedoraproject.org/wiki/JBossAS7\"\u003eFedora/JBoss AS stuff\u003c/a\u003e for\nquite some time. The good (?) news is that I\u0026rsquo;m back to \u003cem\u003ereal\u003c/em\u003e programming.\nSince a couple of months I\u0026rsquo;m helping with \u003ca\nhref=\"http://torquebox.org/\"\u003eTorqueBox\u003c/a\u003e, expecially in the messaging space.\nThis is a great opportunity to share this cool stuff with people.\u003c/p\u003e\n\u003cimg style=\"padding: 5px; float: left; margin-right: 10px;\" alt=\"GeeCON\" src=\"/images/geecon.png\" /\u003e\n\u003cp\u003eI\u0026rsquo;ve decided to submit my first ever talk to \u003ca\nhref=\"http://2013.geecon.org/\"\u003eGeeCON\u003c/a\u003e and it was accepted, yay! I know the\nconference pretty well and I enjoy it every time I\u0026rsquo;m attending. This is also\ntrue to the \u003ca href=\"http://2013.geecon.org/openspaces\"\u003eOpenSpaces\u003c/a\u003e co-event\nwhich is held the day after the main conference (this year it\u0026rsquo;s 18th May). For\nmore information about the conference please reach out to the \u003ca\nhref=\"http://2013.geecon.org/\"\u003econference page\u003c/a\u003e.\u003c/p\u003e","title":"GeeCON 2013"},{"content":"There are many tools that use JMX connections which can be useful for debugging and performance tunning of your applications running on the JVM. The most used are JConsole (shipped with every JDK) and VisualVM (available to download on Oracle page).\nBut before I show how to connect them to JBoss AS we need to understand a few concepts.\nStandalone and domain mode JBoss AS can be run in either standalone or domain mode. I won\u0026rsquo;t explain in detail the difference between those two here because this is a topic for another blog post. The most important difference is that in domain mode you can manage a set of JBoss AS instances using one management entry point compared to starting just one server in standalone mode. It depends on your use case which mode you should use - both have pros and cons.\nNo matter which mode you choose you will be able to connect to the instance(s) using a remoting connector to access JMX. Please note that the connection configuration is different depending on which mode you choose.\nClasspath changes To be able to connect to the remote JMX you need to add a few libraries to the classpath.\nOptionalYou can skip this part if you're going to connect to local processes and don't want to have the JBoss CLI integrated with JConsole. In any other case this step is required. JConsole If you use JConsole, you\u0026rsquo;re lucky, because the JBoss AS team ships a wrapper script for JConsole. You can find it in $JBOSS_HOME/bin/jconsole.sh. As a bonus you get access to the JBoss AS CLI directly from JConsole.\nVisualVM If you want to use VisualVM, I adjusted a wrapper script, found originally on akquinet blog. This script will make it easy to launch VisualVM with the required libraries on the classpath for both JBoss AS 7 and 8.\nYou may need to adjust the VISUALVM path to the VisualVM executable before you proceed.\nConnections Now, that we have our monitoring applications set up with the correct classpath, we\u0026rsquo;re ready to connect to a local or remote instance.\nLocal processes This is when the monitoring application and the JBoss AS instance are running on one host.\nModeThis works in both standalone and domain mode. There are no classpath preparations required to connect JConsole or VisualVM to a local process. But if you want to use the integrated CLI with JConsole you need to use the jconsole.sh wrapper script mentioned earlier.\nIn this case, no authentication is necessary since connections from the same host are automatically allowed.\nTo begin just start the selected application (JConsole or Visual VM), choose the appropriate Java process from the list and you\u0026rsquo;re ready.\nRemote process with password authentication and native port This is when the monitoring application and the JBoss AS instance are running on different hosts and we connect to the native management port.\nModeThis works in standalone mode only. Port visibility To connect using the native port you need to make sure the JBoss AS management interface is visible from the client host.\nBy default the management interface is bound to 127.0.0.1. To change the management interface address to bind to, you can use the jboss.bind.address.management property, like this:\n$ bin/standalone.sh -Djboss.bind.address.management=IP_ADDRESS You can also make it persistent using the JBoss CLI ($JBOSS_HOME/bin/jboss-cli.sh) using this call:\n# /interface=management/:write-attribute(name=inet-address,value=IP_ADDRESS) You can use the same call for domain mode, but please be aware this will not make the native management port available for JMX connections. For remote connections to JBoss AS running in domain mode see the remoting port described below.\nRestart requiredPlease note that a JBoss AS restart is required to apply the above change. The native management endpoint is exposed by default on port 9999.\nManagement user creation To be able to authenticate with the remote host we need to create a management user using the $JBOSS_HOME/bin/add-user.sh script.\n$ bin/add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a Enter the details of the new user to add. Realm (ManagementRealm) : Username : test Password : Re-enter Password : About to add user 'test' for realm 'ManagementRealm' Is this correct yes/no? yes Added user 'test' to file '/home/jboss/standalone/configuration/mgmt-users.properties' Added user 'test' to file '/home/jboss/domain/configuration/mgmt-users.properties' Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller? yes/no? yes To represent the user add the following to the server-identities definition \u0026lt;secret value=\u0026quot;cWF6IUAjMTIz\u0026quot; /\u0026gt; Connection Now we\u0026rsquo;re ready to connect to the remote instance. The connection string should look similar to this:\nservice:jmx:remoting-jmx://HOST:9999 Classpath entriesThis connection type requires the modified classpath changes described above. In the username and password fields please enter the valid credentials for the management user you created earlier.\nRemote process with password authentication and remoting port This is when the monitoring application and the JBoss AS instance are running on different hosts and we connect to the remoting port.\nModeThis works in both standalone and domain mode. Port visibility To connect using the remoting port you need to make sure the JBoss AS instance is visible from the client host.\nDifferencePlease note that the configuration described here is different from the native management configuration above. By default JBoss AS is bound to 127.0.0.1. To change the address to bind to, you can use the -b switch when starting JBoss AS, like this:\n$ bin/standalone.sh -b IP_ADDRESS You can also make it persistent using the JBoss CLI ($JBOSS_HOME/bin/jboss-cli.sh) using this call:\n# /interface=public/:write-attribute(name=inet-address,value=IP_ADDRESS) Restart requiredPlease note that a JBoss AS restart is required to apply the above change. The remoting endpoint is exposed by default on port 4447. If you start JBoss AS in domain mode then the remoting port of the first instance will be exposed on port 4447 but later instances will add an offset to this port. By default the offset is equal to 150 so the second instance will use port 4597 as the remoting port, the third 4747, and so on.\nApplication user creation To be able to authenticate with the remote host using the remoting port we need to create an application user using the $JBOSS_HOME/bin/add-user.sh script.\n$ bin/add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): b Enter the details of the new user to add. Realm (ApplicationRealm) : Username : test Password : Re-enter Password : What roles do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: About to add user 'test' for realm 'ApplicationRealm' Is this correct yes/no? yes Added user 'test' to file '/home/goldmann/jira/TORQUE-1039-remote-jmx/jboss-as-7.1.2.Final/standalone/configuration/application-users.properties' Added user 'test' to file '/home/goldmann/jira/TORQUE-1039-remote-jmx/jboss-as-7.1.2.Final/domain/configuration/application-users.properties' Added user 'test' with roles to file '/home/goldmann/jira/TORQUE-1039-remote-jmx/jboss-as-7.1.2.Final/standalone/configuration/application-roles.properties' Added user 'test' with roles to file '/home/goldmann/jira/TORQUE-1039-remote-jmx/jboss-as-7.1.2.Final/domain/configuration/application-roles.properties' Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller? yes/no? yes To represent the user add the following to the server-identities definition \u0026lt;secret value=\u0026quot;cWF6IUAjMTIz\u0026quot; /\u0026gt; Configuration By default you can connect to JBoss AS to access JMX using the native management interface. To use the remoting interface you need to manualy change the JBoss AS configuration.\nYou cannot use bothWhen you decide to change the configuration and use the remoting endpoint for JMX access, the native management endpoint will stop working. You cannot use both endpoints on one host. You can change this by using the JBoss CLI. For standalone mode:\n# /subsystem=jmx/remoting-connector=jmx/:write-attribute(name=use-management-endpoint,value=false) Due to a bug in JBoss CLI you cannot set this for domain mode, but you uncomment the following line from the full profile to enable it (assuming that you are using the default configuration which utilizes the full profile):\n\u0026lt;remoting-connector use-management-endpoint=\u0026quot;false\u0026quot;/\u0026gt; Restart requiredPlease note that a JBoss AS restart is required to apply the above change. Connection Now we\u0026rsquo;re ready to connect to the remote instance. The connection string should look similar to this:\nservice:jmx:remoting-jmx://HOST:4447 When you\u0026rsquo;re trying to connect to the second instance of the JBoss AS in domain mode, you\u0026rsquo;ll need to add the default offset (150) to the port number.\nClasspath entriesThis connection type requires the modified classpath changes described above. In the username and password fields please enter the valid credentials for the application user you created earlier.\nTroubleshooting You may encounter some issues while connecting, please check that:\nThe instance is running and the port you\u0026rsquo;re trying to connect to reachable. Make sure you choose the right port (management vs. remoting). Make sure you made the required changes (if any) to the JBoss AS configuration. ","permalink":"https://goldmann.pl/blog/2013/04/16/jmx-connections-to-jboss-as/","summary":"\u003cp\u003eThere are many tools that use JMX connections which can be useful for\ndebugging and performance tunning of your applications running on the JVM. The\nmost used are JConsole (shipped with every JDK) and VisualVM (available to\ndownload on \u003ca href=\"http://visualvm.java.net/\"\u003eOracle page\u003c/a\u003e).\u003c/p\u003e\n\u003cp\u003eBut before I show how to connect them to JBoss AS we need to understand a few\nconcepts.\u003c/p\u003e\n\u003ch2 id=\"standalone-and-domain-mode\"\u003eStandalone and domain mode\u003c/h2\u003e\n\u003cp\u003eJBoss AS can be run in either \u003cstrong\u003estandalone\u003c/strong\u003e or \u003cstrong\u003edomain\u003c/strong\u003e mode. I won\u0026rsquo;t explain in\ndetail the difference between those two here because this is a topic for\nanother blog post.  The most important difference is that in domain mode you\ncan manage a set of JBoss AS instances using one management entry point\ncompared to starting just one server in standalone mode. It depends on your use\ncase which mode you should use - both have pros and cons.\u003c/p\u003e","title":"JMX connections to JBoss AS"},{"content":"\nIn Fedora when you run virt-manager you\u0026rsquo;ll be asked for your password. Since I use this tool a lot I would like to have a password-less virt-manager.\nThank Jebus we have polkit where we can define authentication rules. There was a handy rule available written by Rich, but it stopped to work with the release of Fedora 18 because polkit changed completely the language used in rules files. Since polkit-0.106 the new rules files are written in JavaScript. Yes, JavaScript. More info about the choice you can find on David\u0026rsquo;s blog post.\nTo access virt-manager without entering password, just a create a file named /etc/polkit-1/rules.d/80-libvirt-manage.rules (or similar) with following content:\npolkit.addRule(function(action, subject) { if (action.id == \"org.libvirt.unix.manage\" \u0026\u0026 subject.local \u0026\u0026 subject.active \u0026\u0026 subject.isInGroup(\"wheel\")) { return polkit.Result.YES; } }); Remember to add your user to the wheel group:\nusermod -a -G wheel goldmann That\u0026rsquo;s all, enjoy!\n","permalink":"https://goldmann.pl/blog/2012/12/03/configuring-polkit-in-fedora-18-to-access-virt-manager/","summary":"\u003cp\u003e\u003ca class=\"picture\" href=\"/images/polkit_virt-manager.png\" title=\"virt-manager authentication\"\u003e\u003cimg style=\"float:right; border: 1px solid #eee; padding: 5px; margin-left: 5px; width: 50%;\" alt=\"virt-manager authentication\" src=\"/images/polkit_virt-manager.png\" /\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eIn \u003ca href=\"https://fedoraproject.org/\"\u003eFedora\u003c/a\u003e when you run \u003ca href=\"http://virt-manager.org/\"\u003e\u003ccode\u003evirt-manager\u003c/code\u003e\u003c/a\u003e you\u0026rsquo;ll be asked for your password. Since I use this tool a lot I would like to have a password-less virt-manager.\u003c/p\u003e\n\u003cp\u003eThank \u003ca href=\"http://en.wikipedia.org/wiki/Jebus\"\u003eJebus\u003c/a\u003e we have \u003ca href=\"http://en.wikipedia.org/wiki/Polkit\"\u003epolkit\u003c/a\u003e where we can define authentication rules. There was a \u003ca href=\"http://www.outsidaz.org/blog/2010/10/15/configuring-policykit-access-to-virt-manager/\"\u003ehandy rule available written by Rich\u003c/a\u003e, but it stopped to work with the release of Fedora 18 because polkit changed completely the language used in rules files. Since \u003ccode\u003epolkit-0.106\u003c/code\u003e the \u003cstrong\u003enew rules files are written in JavaScript\u003c/strong\u003e. Yes, JavaScript. More info about the choice you can find on \u003ca href=\"http://davidz25.blogspot.com/2012/06/authorization-rules-in-polkit.html\"\u003eDavid\u0026rsquo;s blog post\u003c/a\u003e.\u003c/p\u003e","title":"Configuring polkit in Fedora 18 to access virt-manager"},{"content":"Version infoNew features mentioned in this post are available in jboss-as-7.1.1-11 or newer. Until now the webservices support was not available in the Fedora packaged JBoss AS. The main issue was the lack of CXF stack in Fedora. It took some time to make it available in an RPMified version since CXF is a pretty big project, with many submodules and a pretty nice dependency tree.\nCurrently in Fedora we have JBoss AS available in version 7.1.1.Final which requires CXF 2.4.6. This is a pretty old release. I decided to upgrade the CXF stack to the latest available release from the 2.6.x series. This triggered updating the jbossws-* stack to newer versions than shipped with JBoss AS 7.1.1.Final. I did some tests and it seems that the components integrate with JBoss AS seamlessly. Either case please test your application with the new stack and report any bugs.\nSample application To ensure the webservices integration works as expected I created a small application.\npackage pl.goldmann.as7.ws; import javax.jws.WebMethod; import javax.jws.WebService; @WebService public interface Calculator { @WebMethod public float add(float a, float b); @WebMethod public float sub(float a, float b); @WebMethod public float multiply(float a, float b); @WebMethod public float divide(float a, float b); } As you can see the webservice is a very simple calculator with four basic operations. You can build the application by executing mvn package. I used the jboss-cli command to deploy the application to JBoss AS:\n[standalone@localhost:9999 /] deploy /home/goldmann/tmp/webservices.war And here is the JBoss AS log:\n13:26:07,705 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of \"webservices.war\" 13:26:08,749 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-2) JBWS024061: Adding service endpoint metadata: id=CalculatorWS address=http://jboss-as:8080/webservices implementor=pl.goldmann.as7.ws.CalculatorWS invoker=org.jboss.wsf.stack.cxf.JBossWSInvoker serviceName={http://ws.as7.goldmann.pl/}CalculatorWS portName={http://ws.as7.goldmann.pl/}CalculatorWSPort wsdlLocation=null mtomEnabled=false 13:26:09,597 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-2) Creating Service {http://ws.as7.goldmann.pl/}CalculatorWS from class pl.goldmann.as7.ws.Calculator 13:26:11,458 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-2) Setting the server's publish address to be http://jboss-as:8080/webservices 13:26:11,781 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-2) JBWS024074: WSDL published to: file:/var/lib/jboss-as/standalone/data/wsdl/webservices.war/CalculatorWS.wsdl 13:26:11,793 INFO [org.jboss.as.webservices] (MSC service thread 1-4) JBAS015539: Starting service jboss.ws.port-component-link 13:26:11,824 INFO [org.jboss.as.webservices] (MSC service thread 1-6) JBAS015539: Starting service jboss.ws.endpoint.\"webservices.war\".CalculatorWS 13:26:11,899 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022050: Endpoint registered: jboss.ws:context=webservices,endpoint=CalculatorWS 13:26:12,335 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018210: Registering web context: /webservices 13:26:12,548 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed \"webservices.war\" You can see the WSDL by pointing your browser to http://jboss-as:8080/webservices?wsdl.\nHostnameThe example applications use jboss-as as the hostname. You may want to edit the /etc/hosts file and add an entry to map this hostname to a valid IP address. Testing the webservice To test the service I prepared a simple standalone client. You can build it by running mvn package. To start the client just execute:\njava -jar target/webservices-client-1.0.jar and observe the output. It should be similar to what I got.\nAdditionally I ran some basic tests with SoapUI. I was able to create a webservice from WSDL and run some sample requests. You can see the result on the screenshot.\nSummary As you can see the webservice stack in JBoss AS in Fedora works! Of course all you saw above are basic tests. If you have something more fancy, go for it and let me know how it went.\n","permalink":"https://goldmann.pl/blog/2012/11/26/webservices-support-in-jboss-as-in-fedora/","summary":"\u003cdiv class=\"alert alert-info\"\u003e\u003ch4\u003eVersion info\u003c/h4\u003eNew features mentioned in this post are available in \u003ccode\u003ejboss-as-7.1.1-11\u003c/code\u003e or newer.\u003c/div\u003e\n\u003cp\u003eUntil now the webservices support was not available in the \u003ca href=\"http://fedoraproject.org/\"\u003eFedora\u003c/a\u003e packaged JBoss AS. The main issue was the lack of \u003ca href=\"http://cxf.apache.org/\"\u003eCXF stack\u003c/a\u003e in Fedora. It took some time to make it available in an RPMified version since CXF is a pretty big project, with many submodules and a pretty nice dependency tree.\u003c/p\u003e\n\u003cp\u003eCurrently in Fedora we have JBoss AS available in version \u003ccode\u003e7.1.1.Final\u003c/code\u003e which requires CXF \u003ccode\u003e2.4.6\u003c/code\u003e. This is a pretty old release. I decided to \u003cstrong\u003eupgrade the CXF stack\u003c/strong\u003e to the latest available release from the \u003ccode\u003e2.6.x\u003c/code\u003e series. This triggered updating the \u003ccode\u003ejbossws-*\u003c/code\u003e stack to newer versions than shipped with JBoss AS \u003ccode\u003e7.1.1.Final\u003c/code\u003e. I did some tests and it seems that the components integrate with JBoss AS seamlessly. Either case please test your application with the new stack and \u003ca href=\"https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora\u0026amp;component=jboss-as\"\u003ereport any bugs\u003c/a\u003e.\u003c/p\u003e","title":"Webservices support in JBoss AS in Fedora"},{"content":"When you develop an application, sometimes you want to run it quickly and test it manually. Sometimes you want to execute some integration tests that require database access. In all of these cases you need a working database. Thanks to JPA providers we can generate the database schema based on the entity definitions. Let\u0026rsquo;s quickly look at two of them: Hibernate and OpenJPA.\nHibernate configuration I\u0026rsquo;m sure you have used Hibernate before. Did you know that it has a nice feature that generates the schema in the database at application startup? You can additionally place any SQL statements you want to execute after the creation of the schema into file called import.sql.\nTo enable the schema generation in Hibernate add the following property to persistence.xml:\n\u0026lt;property name=\u0026quot;hibernate.hbm2ddl.auto\u0026quot; value=\u0026quot;create-drop\u0026quot;/\u0026gt; It works perfectly in JBoss AS 7.\nThe value create-drop means that the database schema will be created at application deploy time and removed when you undeploy it. There are other possible values like validate, update and create.\nBy default, Hibernate will search for the import.sql file in the root of the classpath of the produced archive. For a WAR file, it is located at WEB-INF/classes/import.sql, but if you generate a regular JAR just place the import.sql in the root of the file.\nIf you want to change the location of the file use hibernate.hbm2ddl.import_files. As the property name suggests, you can specify more than one file.\nRead more about the Hibernate properties you can use in the Miscellaneous Properties table located in the Hibernate documentation.\nOpenJPA configuration OpenJPA includes a similar feature. You can generate the schema by using the provided MappingTool. MappingTool allows you to run the generation even from a command line. In our case, the more interesting feature is running it at application deploy time so that we automatically get a working schema in our database.\nTo make it work at runtime we need to add a openjpa.jdbc.SynchronizeMappings property to persistence.xml:\n\u0026lt;property name=\u0026quot;openjpa.jdbc.SynchronizeMappings\u0026quot; value=\u0026quot;buildSchema\u0026quot;/\u0026gt; Additionally we need to list all the classes for which we want to generate the schema in our persistence unit so that OpenJPA knows about these classes at startup. Just use the \u0026lt;class/\u0026gt; marker, for example:\n\u0026lt;class\u0026gt;pl.goldmann.as7.model.Chair\u0026lt;/class\u0026gt; In JBoss AS 7 we need to force the initialization of the OpenJPA persistence unit that generates the schema at deployment time to actually trigger the schema generation. It\u0026rsquo;s very simple, just add another property:\n\u0026lt;property name=\u0026quot;openjpa.InitializeEagerly\u0026quot; value=\u0026quot;true\u0026quot;/\u0026gt; I\u0026rsquo;m not sure if OpenJPA has a built-in feature to execute SQL statements after schema generation like Hibernate. If you know how to do it, please speak up.\nAnd that\u0026rsquo;s it. It\u0026rsquo;s a simple to implement but handy feature.\n","permalink":"https://goldmann.pl/blog/2012/08/24/generate-a-database-schema-with-openjpa-and-hibernate-on-jboss-as-7/","summary":"\u003cp\u003eWhen you develop an application, sometimes you want to run it quickly and test it manually. Sometimes you want to execute some integration tests that require database access. In all of these cases you need a working database. Thanks to JPA providers we can generate the database schema based on the entity definitions. Let\u0026rsquo;s quickly look at two of them: \u003ca href=\"http://www.hibernate.org/\"\u003eHibernate\u003c/a\u003e and \u003ca href=\"http://openjpa.apache.org/\"\u003eOpenJPA\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"hibernate-configuration\"\u003eHibernate configuration\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;m sure you have used \u003ca href=\"http://www.hibernate.org/\"\u003eHibernate\u003c/a\u003e before. Did you know that it has a nice feature that generates the schema in the database at application startup? You can additionally place any \u003ca href=\"http://en.wikipedia.org/wiki/SQL\"\u003eSQL\u003c/a\u003e statements you want to execute after the creation of the schema into file called \u003ccode\u003eimport.sql\u003c/code\u003e.\u003c/p\u003e","title":"Generate a database schema with OpenJPA and Hibernate on JBoss AS 7"},{"content":"With the upcoming new release of the JBoss AS package in Fedora you\u0026rsquo;ll be able to use both the Hibernate 3 and OpenJPA JPA providers. The reason why I\u0026rsquo;m enabling this for you is that we still don\u0026rsquo;t have Hibernate 4 packaged, which is a pity since Hibernate 4 is the default JPA provider in JBoss AS 7. If you want to help us with it, please consider reviewing the Gradle package.\nSample application I crafted a small application that shows how to use the two new providers. The full source code is available from my GitHub account. This application uses JSF and CDI in addition to JPA. And yes, I use both JPA providers at the same time.\nConfiguration files Let\u0026rsquo;s take a look at the persistence.xml file, since this is the most important part of the application.\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;persistence version=\u0026quot;2.0\u0026quot; xmlns=\u0026quot;http://java.sun.com/xml/ns/persistence\u0026quot; xmlns:xsi=\u0026quot;http://www.w3.org/2001/XMLSchema-instance\u0026quot; xsi:schemaLocation=\u0026quot; http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd\u0026quot;\u0026gt; \u0026lt;persistence-unit name=\u0026quot;hibernate3PU\u0026quot;\u0026gt; \u0026lt;jta-data-source\u0026gt;java:jboss/datasources/ExampleDS\u0026lt;/jta-data-source\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;property name=\u0026quot;hibernate.hbm2ddl.auto\u0026quot; value=\u0026quot;create-drop\u0026quot;/\u0026gt; \u0026lt;property name=\u0026quot;hibernate.show_sql\u0026quot; value=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;property name=\u0026quot;jboss.as.jpa.providerModule\u0026quot; value=\u0026quot;org.hibernate:3\u0026quot;/\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;/persistence-unit\u0026gt; \u0026lt;persistence-unit name=\u0026quot;openjpaPU\u0026quot;\u0026gt; \u0026lt;provider\u0026gt;org.apache.openjpa.persistence.PersistenceProviderImpl\u0026lt;/provider\u0026gt; \u0026lt;jta-data-source\u0026gt;java:jboss/datasources/ExampleDS\u0026lt;/jta-data-source\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;property name=\u0026quot;jboss.as.jpa.providerModule\u0026quot; value=\u0026quot;org.apache.openjpa\u0026quot;/\u0026gt; \u0026lt;property name=\u0026quot;jboss.as.jpa.adapterModule\u0026quot; value=\u0026quot;org.jboss.as.jpa.openjpa\u0026quot;/\u0026gt; \u0026lt;property name=\u0026quot;jboss.as.jpa.adapterClass\u0026quot; value=\u0026quot;org.jboss.as.jpa.openjpa.OpenJPAPersistenceProviderAdaptor\u0026quot;/\u0026gt; \u0026lt;property name=\u0026quot;openjpa.Log\u0026quot; value=\u0026quot;DefaultLevel=WARN, Runtime=INFO, Tool=INFO, SQL=TRACE\u0026quot;/\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;/persistence-unit\u0026gt; \u0026lt;/persistence\u0026gt; As you can see I create two persistence units. Both use the ExampleDS datasource shipped with JBoss AS (it\u0026rsquo;s an in-memory H2 database).\nPlease examine the jboss.as.jpa.* properties carefully. They tell JBoss AS which provider you want to use and how it should initialized.\nHibernate 3 Persistence Unit Since Hibernate 3 is initially configured in JBoss AS 7 the only thing you need to provide is the jboss.as.jpa.providerModule property. Simple.\nOpenJPA Persistence Unit With OpenJPA it is a bit different. Besides the providerModule we need to additionally configure the adapterModule and adapterClass properties. This will be not necessary after the next stable JBoss AS 7 release. But we\u0026rsquo;ll need to do this until then.\nOther stuff Additionally I enabled logging of the SQL statement execution, just for clarity.\nThe import.sql file contains some sample data to populate the database on application startup. It\u0026rsquo;s a Hibernate feature and will be used in our case by the Hibernate 3 provider only.\nModel The only entity class in this application is the Chair class. It\u0026rsquo;s simple, and not worth discussing here.\nEntity enhancement in OpenJPAOpenJPA requires entity enhancement. There are several ways to do this. For this application I use the openjpa-maven-plugin. CDI beans There are two CDI beans for interacting with the view and two for getting data from the database using different providers. This application uses only one database, so data entered with one provider will be accessible from the other one. Here you can see the power of JPA, where there is only one entity configured and it works across different providers. Nice!\nThe Hibernate3Bean.java and OpenJPABean.java files are almost the same - the only difference is in the injection of specific Database interface implementations.\nView The view is written in JSF. It\u0026rsquo;s very simple to understand, so go straight to the code.\nConclusion It\u0026rsquo;s easy to use Hibernate 3 and OpenJPA with JBoss AS 7. It\u0026rsquo;s even easier with the jboss-as package provided with Fedora. The upstream tarball requires some manual work to get it running, in Fedora you get it for free.\nAvailable in next jboss-as package updatePlease note that both Hibernate 3 and OpenJPA providers will be available **with the next** `jboss-as` package update, version **7.1.1-7**. If you have any issues ask in the comments or report a bug directly.\nUpdate 24.08.2012 The jboss-as-7.1.1-7 package was submitted as an update for Fedora 17 and Fedora 18, please test it and bump the karma. This kind of feedback is very important.\n","permalink":"https://goldmann.pl/blog/2012/08/22/openjpa-and-hibernate-3-on-jboss-as-in-fedora/","summary":"\u003cp\u003eWith the upcoming new release of the \u003ca href=\"http://www.jboss.org/as7\"\u003eJBoss AS\u003c/a\u003e package in Fedora you\u0026rsquo;ll be able to use both the \u003ca href=\"http://www.hibernate.org/\"\u003eHibernate\u003c/a\u003e 3 and \u003ca href=\"http://openjpa.apache.org/\"\u003eOpenJPA\u003c/a\u003e JPA providers. The reason why I\u0026rsquo;m enabling this for you is that we still don\u0026rsquo;t have Hibernate 4 packaged, which is a pity since Hibernate 4 is the default JPA provider in JBoss AS 7. \u003cstrong\u003eIf you want to help us\u003c/strong\u003e with it, please consider \u003ca href=\"https://bugzilla.redhat.com/show_bug.cgi?id=809950\"\u003ereviewing the Gradle package\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"sample-application\"\u003eSample application\u003c/h2\u003e\n\u003cp\u003eI crafted a small application that shows how to use the two new providers. The full source code is available \u003ca href=\"https://github.com/goldmann/jboss-as-hibernate3-openjpa\"\u003efrom my GitHub account\u003c/a\u003e. This application uses JSF and CDI in addition to JPA. And yes, I use \u003cstrong\u003eboth\u003c/strong\u003e JPA providers at the same time.\u003c/p\u003e","title":"OpenJPA and Hibernate 3 on JBoss AS in Fedora"},{"content":"I\u0026rsquo;m very happy to let you know that I pushed today a new update for jboss-as package to Fedora.\nNew stuff The 7.1.1-4 version includes a lot of new modules as well as some design changes, let\u0026rsquo;s go briefly over them.\nStability The most important change from a RPM/build stability POV is the move from building minimalistic to default profile. This let me know to drop about 60 (sic!) patches from the jboss-as.spec.\nSince the change wasn\u0026rsquo;t\u0026rsquo;s trivial because it required rebasing and manual merging of previous patches I hereby ask you for help with testing. I did my best to eliminate bugs, but\u0026hellip; Please install the new update and check if everything works for you. It is very important that you add karma on that page (remember to log in first!). This package will go into stable only if it hits the threshold of 4 positive karma, I\u0026rsquo;m not going to force push it like I did previously. Keep that in mind and encourage others.\nNew subsystem available New update, new modules added. Mostly OSGi stuff, but also some Arquillian goodness.\norg.jboss.as.modcluster module org.jboss.as.jsr77 module org.jboss.as.arquillian org.jboss.as.osgi org.jboss.as.configadmin org.jboss.as.spec-api If you\u0026rsquo;re interested in some of them, please test the integration.\nA few bugs fixed There were few bugs reported, one was hanging for some time in my queue.\nRHBZ#827571 - jboss-as-cp script is missing argument placeholder for c optarg RHBZ#827588 - Create a startup script when creating a new user instance (jboss-as-cp) RHBZ#827589 - The user instance create script (jboss-as-cp) should allow a port offset to be specified RHBZ#812522 - Add ExampleDS based on H2 database How to get it The simplest way is to wait for the package to hit Fedora\u0026rsquo;s updates-testing repository. This should be done by tomorrow. Remember that you\u0026rsquo;ll need to have updates-testing repository enabled on your system. Do not install jboss-as-7.1.1-4 without updates-testing enabled and without up to date packages on your system. You have been warned.\nOne more thing\u0026hellip; \u0026quot;Don't mess with coders\u0026quot; In the early days of packaging JBoss AS into Fedora I had a conversation with Alexander Kurtakov (aka The Fedora Eclipse Guy). He told me that he\u0026rsquo;ll take a picture of himself in the JBoss AS t-shirt once the jboss-as package hits Fedora repositories. Well, this is now reality, so here is the pic :)\nNeed help? Feel free to report any bugs in #fedora-java IRC channel or directly in Bugzilla.\n","permalink":"https://goldmann.pl/blog/2012/07/04/jboss-as-7.1.1-4-update-pushed-to-fedora/","summary":"\u003cp\u003eI\u0026rsquo;m very happy to let you know that I \u003ca href=\"https://admin.fedoraproject.org/updates/jboss-as-7.1.1-4.fc17\"\u003epushed today a new update\u003c/a\u003e for \u003ccode\u003ejboss-as\u003c/code\u003e package to Fedora.\u003c/p\u003e\n\u003ch2 id=\"new-stuff\"\u003eNew stuff\u003c/h2\u003e\n\u003cp\u003eThe \u003ccode\u003e7.1.1-4\u003c/code\u003e version \u003cstrong\u003eincludes a lot of new modules\u003c/strong\u003e as well as some design changes, let\u0026rsquo;s go briefly over them.\u003c/p\u003e\n\u003ch3 id=\"stability\"\u003eStability\u003c/h3\u003e\n\u003cp\u003eThe most important change from a RPM/build stability POV is the move from building \u003cem\u003eminimalistic\u003c/em\u003e to \u003cem\u003edefault\u003c/em\u003e profile. This let me know to \u003cstrong\u003edrop about 60\u003c/strong\u003e (sic!) patches from the \u003ccode\u003ejboss-as.spec\u003c/code\u003e.\u003c/p\u003e","title":"JBoss AS 7.1.1-4 update pushed to Fedora"},{"content":"I have at home a pretty nice server: HP ML350 G5. My model has one Quad-Core Intel Xeon Processor X5355 (2.66 GHz), 8 GB of RAM and 4x 250 GB SATA II, 2.5\u0026rsquo;\u0026rsquo;, 5.4k disk drives.\nI have this HW for over three years now, but never really tried to do anything besides installing an operating system and grinding some boxes. Recently I decided to run some quick tests to see the actual performance of the disks.\nThe machine has an built-in array controller: HP Smart Array E200i with 128MB BBWC [pdf, 149KB]. There are a lot of resources on the web saying that this is a piece of crap. This wasn\u0026rsquo;t very optimistic.\nThe E200i controller supports following, basic RAID versions: 0, 1+0, 5.\nThe reason I started searching for possible speed improvements was the (subjective) feeling that the disks are simply slow. I tried every RAID level, but wasn\u0026rsquo;t satisfied even with 0. I haven\u0026rsquo;t had any good numbers at that time though.\nSo I booted CentOS 6 LiveCD and started the Disk Utility and run the read-write benchmarks. The results are below.\nAll presented RAID logical disks were created using default settings and included all 4 disks for each level. Uh. Ah\u0026hellip; I knew the performance wasn\u0026rsquo;t great but I wasn\u0026rsquo;t expecting such horrible write performance. I\u0026rsquo;m pretty happy with read performance though. Remember: these are 2.5\u0026rsquo;\u0026rsquo; 5.4k disks, so nothing very fancy.\nI started to crawl the web for solutions for this problem. I found ACU. HP\u0026rsquo;s Array Configuration Utility provides an easy way to view and change the configuration of the arrays. I didn\u0026rsquo;t bother myself with the gui version, I used CLI, which works just fine. You can download it from here. I installed it on the running LiveCD and started to poke around. HP ships a nice manual for using ACU [pdf, 1.8MB].\nTo list the status of the array controller, just run the CLI: hpacucli and execute the ctrl slot=\u0026quot;0\u0026quot; show command, like this:\n[root@livecd ~]# hpacucli HP Array Configuration Utility CLI 9.0-24.0 Detecting Controllers...Done. Type \"help\" for a list of supported commands. Type \"exit\" to close the console. =\u003e ctrl slot=\"0\" show Smart Array E200i in Slot 0 (Embedded) Bus Interface: PCI Slot: 0 Cache Serial Number: P9A3A0B9SWM13U RAID 6 (ADG) Status: Disabled Controller Status: OK Hardware Revision: A Firmware Version: 1.82 Rebuild Priority: Medium Expand Priority: Medium Surface Scan Delay: 15 secs Surface Scan Mode: Idle Post Prompt Timeout: 0 secs Cache Board Present: True Cache Status: OK Accelerator Ratio: 50% Read / 50% Write Drive Write Cache: Disabled Total Cache Size: 128 MB Total Cache Memory Available: 96 MB No-Battery Write Cache: Disabled Cache Backup Power Source: Batteries Battery/Capacitor Count: 1 Battery/Capacitor Status: OK SATA NCQ Supported: False After quick look at the output we can see this line:\nDrive Write Cache: Disabled I found on the web that enabling DWC and setting it to 100% read and 0% write ratio improves the peroformance significantly. I changed the values using these commands:\n=\u003e ctrl slot=0 modify cacheratio=100/0 =\u003e ctrl slot=0 modify dwc=enable Warning: Without the proper safety precautions, use of write cache on physical drives could cause data loss in the event of power failure. To ensure data is properly protected, use redundant power supplies and Uninterruptible Power Supplies. Also, if you have multiple storage enclosures, all data should be mirrored across them. Use of this feature is not recommended unless these precautions are followed. Continue? (y/n) y Results are quite interesting!\nAfterwards I experimented with the cache ratio but the settings 100% / 0% seems to be the best.\nWhen ratio was set to, for example 50% / 50% (default value) the performance was better than with DWC disabled, but not as good as with 100% / 0%. At least for my tests. Maybe a specific usage of the disks will require different settings.\nWarning! HP itself doesn't recommend enabling DWC for mission-critical systems and for systems without proper power infrastructure (redundancy, UPS, etc) because in case of a power outage it may destroy your data. Ouch. Assuming we have proper power backup (I have an APC Smart-UPS connected to the box) we can go ahead and get some performance.\n","permalink":"https://goldmann.pl/blog/2012/05/13/hp-smart-array-e200i-performance/","summary":"\u003cp\u003eI have at home a pretty nice server: \u003ca href=\"http://h18004.www1.hp.com/products/quickspecs/12475_na/12475_na.HTML\"\u003eHP ML350 G5\u003c/a\u003e. My model has one Quad-Core Intel Xeon Processor X5355 (2.66 GHz), 8 GB of RAM and 4x 250 GB SATA II, 2.5\u0026rsquo;\u0026rsquo;, 5.4k disk drives.\u003c/p\u003e\n\u003cp\u003eI have this HW for over three years now, but never really tried to do anything besides installing an operating system and \u003ca href=\"http://boxgrinder.org/\"\u003egrinding some boxes\u003c/a\u003e. Recently I decided to run some quick tests to see the actual performance of the disks.\u003c/p\u003e","title":"HP Smart Array E200i performance"},{"content":"Yesterday we had JBoss AS Test Day. Since the early morning hours we received help with testing the RPM packaged JBoss AS.\nAnd what\u0026rsquo;s the general impression?\nIt works!\nAlmost all test cases we prepared were successfully finished by our community members. We found one issue with not preserving the permission on files when adding new users to JBoss AS management interface. I\u0026rsquo;ve created a fix for that and sent a pull request. Expect to have it fixed in jboss-as-7.1.0-4 package.\nOther than that - we haven\u0026rsquo;t found any issues with running AS7 on Fedora. Which is obviously good. But if you find some, please report them imemdiately as we want to have a great platform for developers.\nPlease note that the shipped AS is not a full AS7 you can download from the website. It is a web profile, but lacking the JPA2 implementation. We\u0026rsquo;re working really hard on extending it.\nThanks to all testers for a good job!\n","permalink":"https://goldmann.pl/blog/2012/04/18/impressions-after-fedora-test-day-for-jboss-application-server/","summary":"\u003cp\u003e\u003ca href=\"/blog/2012/04/17/jboss-as-fedora-test-day-today/\"\u003eYesterday\u003c/a\u003e we had JBoss AS Test Day. Since the early morning hours we received help with testing the \u003ca href=\"http://fedoraproject.org/wiki/JBossAS7\"\u003eRPM packaged\u003c/a\u003e \u003ca href=\"http://www.jboss.org/jbossas\"\u003eJBoss AS\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAnd what\u0026rsquo;s the general impression?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIt works!\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAlmost all \u003ca href=\"https://fedoraproject.org/wiki/Test_Day:2012-04-17_JBoss_Application_Server#Test_Cases\"\u003etest cases we prepared\u003c/a\u003e were successfully finished by our community members. We found one issue with not preserving the permission on files when adding new users to JBoss AS management interface. I\u0026rsquo;ve created a fix for that and \u003ca href=\"https://github.com/jbossas/jboss-as/pull/2067\"\u003esent a pull request\u003c/a\u003e. Expect to have it fixed in \u003ccode\u003ejboss-as-7.1.0-4\u003c/code\u003e package.\u003c/p\u003e","title":"Impressions after Fedora Test Day for JBoss Application Server"},{"content":"We\u0026rsquo;re going today to test the (very) fresh JBoss Application Server which was packaged into Fedora. I hope you have some time to join us!\nWhere I can read more about the test day? Most recent information you can find on the JBoss AS Fedora Test Day wiki page.\nHow should I prepare? Make sure you have a Fedora 17 environment somewhere (VM preferred) with latest updates installed. This is very important.\nWhat we\u0026rsquo;ll test? We\u0026rsquo;ll have some test cases. But you\u0026rsquo;re not limited to these test cases. Feel free to test the server at your own too!\nWhere we\u0026rsquo;ll meet? I am available on IRC in #fedora-test-day channel on freenode.\nHow can I participate? You can help us with testing and proposing test cases! After you execute the test cases, please add your results to the table.\nSee you online!\n","permalink":"https://goldmann.pl/blog/2012/04/17/jboss-as-fedora-test-day-today/","summary":"\u003cp\u003eWe\u0026rsquo;re going today to test the (very) fresh JBoss Application Server which was \u003ca href=\"https://fedoraproject.org/wiki/JBossAS7\"\u003epackaged into Fedora\u003c/a\u003e. I hope you have some time to join us!\u003c/p\u003e\n\u003ch3 id=\"where-i-can-read-more-about-the-test-day\"\u003eWhere I can read more about the test day?\u003c/h3\u003e\n\u003cp\u003eMost recent information you can find on the \u003ca href=\"https://fedoraproject.org/wiki/Test_Day:2012-04-17_JBoss_Application_Server\"\u003eJBoss AS Fedora Test Day wiki page\u003c/a\u003e.\u003c/p\u003e\n\u003ch3 id=\"how-should-i-prepare\"\u003eHow should I prepare?\u003c/h3\u003e\n\u003cp\u003eMake sure you have a Fedora 17 environment somewhere (VM preferred) with latest updates installed. This is \u003cstrong\u003every\u003c/strong\u003e important.\u003c/p\u003e","title":"JBoss AS Fedora Test Day - today!"},{"content":"Below you can find my latest song I made with Makul over the last year. We planned to do a song together since a few years, but it always failed because of lack of time.\nFinally in April this year we met at Makul\u0026rsquo;s house, had a couple of beers and started the work. This is the output of our work. Melody line and part of beat is Makul\u0026rsquo;s work whereas I arrnged and finished the whole thing. A few days ago the song was mastered.\nWhat do you think?\nThis song is lincesed under CC-BY-SA license. The source code is available for download here [17 MB, rns].\n","permalink":"https://goldmann.pl/blog/2011/12/16/new-song-connection/","summary":"\u003cp\u003eBelow you can find my latest song I made with \u003ca href=\"http://www.myspace.com/mokatimakul\"\u003eMakul\u003c/a\u003e over the last year. We planned to do a song together since a few years, but it always failed because of lack of time.\u003c/p\u003e\n\u003cp\u003eFinally in April this year we met at Makul\u0026rsquo;s house, had a couple of beers and started the work. This is the output of our work. Melody line and part of beat is Makul\u0026rsquo;s work whereas I arrnged and finished the whole thing. A few days ago the song was mastered.\u003c/p\u003e","title":"New song: 'Connection'"},{"content":"I\u0026rsquo;m sure there are hundreds of blog posts explaining how to care for an open source community. These are my notes. If you find them useful - that\u0026rsquo;s awesome - if not - please tell me why.\nI\u0026rsquo;m a member of several communities, just to name a few: JBoss, TorqueBox, Fedora Cloud, Fedora Java and of course BoxGrinder.\nI was a lucky enough to have a great teacher who jump-started me in the real meaning of open source. The learning of course isn\u0026rsquo;t over! Every day I learn new things - the Fedora community especially is a big mine of knowledge about open source and communities.\nBoxGrinder Since its beginning I\u0026rsquo;ve the leader of the BoxGrinder project. Our community is small but pretty healthy. We have people writing blog posts, reporting bugs and contributing code. We can discuss with them new ideas and we always receive valuable feedback.\nThanks guys for that - I really appreciate it!\nBeing an open source community leader is not only a great distinction but a great responsibility too. I\u0026rsquo;m sure people like Jared Smith, who\u0026rsquo;s the current Fedora project leader, know this best.\nToday I would like to focus only on one word: openness.\nOpenness Open source community is by definition open. The openness can be considered on many levels, though.\nAs free to join and leave People will come and go. This is their right and you cannot change this. Some of them will be with you longer, some shorter, but at some point every single member will leave the community (hopefully not at the same time :)). There are several reasons why they\u0026rsquo;re doing it: loss of interest, bad atmosphere, job change, new kid on the block, etc.\nThe role of a community leader is to make the community attractive and compelling for people so they leave only when they have no other choice.\nAs removing barriers There should be no barriers to join the community. This is also true for leaving it. It is bad to force people to fill a whole page of contact data just to access the forums. You don\u0026rsquo;t need it, so don\u0026rsquo;t waste people\u0026rsquo;s time!\nForums - require only email address to register. Mailing list - require only sending an email to a well-known address to subscribe. IRC channel - make it easily findable and public, no restrictions to join the conversation. Twitter/Google+/Facebook - use it (wisely!) and wait: patience, patience, patience. The whole community infrastructure must be easy to use and public. No, there is no such thing as private/closed communities.\nAs transparent decisions Decisions making which could impact the community should be transparent. At least the community should know the plan. Ideally it would be when the community takes part in the decision making process. Sometimes it\u0026rsquo;s possible but in many cases community leaders are forced to satisfy the company requirements. As you can imagine such decisions are not always consistent with the community feeling. Be fair and honest with the community if nothing else.\nAs free to criticize and propose new ideas Always listen to what people say. Kind words are good (who doesn\u0026rsquo;t like them?!), but you should really focus on criticism. Don\u0026rsquo;t be offended - constructive criticism always helps in the long term. Without it there would be no progress at all.\nIt\u0026rsquo;s important to listen to others as you don\u0026rsquo;t always have the whole picture of the problem. You\u0026rsquo;re not Alpha and Omega. I\u0026rsquo;m sorry.\nIt\u0026rsquo;s good to listen to others, but it\u0026rsquo;s even better pick up the best ideas they suggest. This simple step can give you two things immediately:\nHappy community: \u0026ldquo;I suggested something and it was put into practice!\u0026rdquo; Happy you: \u0026ldquo;Project is growing, my community is happy, I\u0026rsquo;m happy!\u0026rdquo; Your opinions? Feel free to share your thoughts about openness in the communities in the comments below!\n","permalink":"https://goldmann.pl/blog/2011/12/10/openness-in-the-community/","summary":"\u003cp\u003eI\u0026rsquo;m sure there are hundreds of blog posts explaining how to care for an \u003ca href=\"http://en.wikipedia.org/wiki/Open_source\"\u003eopen source\u003c/a\u003e community. These are my notes. If you find them useful - that\u0026rsquo;s awesome - if not - please tell me why.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m a member of several communities, just to name a few: \u003ca href=\"http://www.jboss.org/\"\u003eJBoss\u003c/a\u003e, \u003ca href=\"http://torquebox.org/\"\u003eTorqueBox\u003c/a\u003e, \u003ca href=\"http://fedoraproject.org/wiki/Cloud_SIG\"\u003eFedora Cloud\u003c/a\u003e, \u003ca href=\"http://fedoraproject.org/wiki/SIGs/Java\"\u003eFedora Java\u003c/a\u003e and of course \u003ca href=\"http://boxgrinder.org/\"\u003eBoxGrinder\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eI was a lucky enough to have a \u003ca href=\"http://bob.mcwhirter.org/\"\u003egreat teacher\u003c/a\u003e who jump-started me in the real meaning of open source. The learning of course isn\u0026rsquo;t over! Every day I learn new things - the \u003ca href=\"http://fedoraproject.org/\"\u003eFedora\u003c/a\u003e community especially is a big mine of knowledge about open source and communities.\u003c/p\u003e","title":"Openness in the community"},{"content":"I always like to listen to music. It’s hard to describe what type of music is my favourite. Maybe something between electro-house, electro-pop, ambient, dub, minimal and microhouse.\nMy favorite artists are (in no particular order): Luomo, Feist, Sacha Funke, Ellen Allien, Lykke Li, Paul Kalkbrenner, Little Dragon, Radiohead, Smolik, Vladislav Delay, Daft Punk… and many others.\nIn my free (what?!) time I try to produce some music myself.\nMy songs Below you can find my published tracks.\n","permalink":"https://goldmann.pl/musically/","summary":"\u003cp\u003eI always like to listen to music. It’s hard to describe what type of music is my favourite. Maybe something between electro-house, electro-pop, ambient, dub, minimal and microhouse.\u003c/p\u003e\n\u003cp\u003eMy favorite artists are (in no particular order): Luomo, Feist, Sacha Funke, Ellen Allien, Lykke Li, Paul Kalkbrenner, Little Dragon, Radiohead, Smolik, Vladislav Delay, Daft Punk… and many others.\u003c/p\u003e\n\u003cp\u003eIn my free (what?!) time I try to produce some music myself.\u003c/p\u003e\n\u003ch2 id=\"my-songs\"\u003eMy songs\u003c/h2\u003e\n\u003cp\u003eBelow you can find my published tracks.\u003c/p\u003e","title":"Musically"},{"content":"From time to time I’m attending various conferences. Sometimes I’m even a speaker. Below you can find list of presentations I gave so far.\nLicense 2014 Docker and JBoss — the perfect combination, Toruń JUG, Oct 2014: slides, demos\nDocker and JBoss — the perfect combination, JUGtoberFest 2014, Poznań, Oct 2014: slides, demos\nRevolution in software distribution called Docker, Y Soft: Technology Hour, Sep 2014: slides, demos\nDocker and JBoss — the perfect combination, Virtual JBoss User Group, Sep 2014: recording, slides, demos\nDocker and JBoss — the perfect combination, Wrocław JUG, Sep 2014: recording, slides, demos\nDocker, Poznań JUG, June 2014: slides\nDocker, WJBUG, June 2014: slides\nDocker — Intro to a revolution, GeeCON, May 2014: slides\n2013 Docker — Introduction, Red Hat, Dec 2013: slides, slides in French (translated by @olberger)\nTorqueBox — Messaging and scheduled jobs made simple, GeeCON, May 2013: slides, demos\n2012 BoxGrinder, Red Hat, Mar 2012: slides\nBoxGrinder, FUDCon Blacksburg, Mar 2012: slides\nBoxGrinder, FOSDEM, Feb 2012: slides\n2011 BoxGrinder, FUDCon Milan, Oct 2011: slides\nTorqueBox — Ruby na sterydach, Silesia RUG, Nov 2011, polish: slides\nTorqueBox — Where Ruby meets CDI, JUDCon London, Oct 2011: slides\nTorqueBox — Gdzie Ruby spotyka CDI, Confitura, Jul 2011, polish: slides\nTorqueBox — Moc Javy Piękno Rubiego, Confitura, Jun 2011, polish: slides\nBoxGrinder, JUDCon Boston, Jun 2011: slides\nBoxGrinder, FUDCon Tempe, Jan 2011: slides\n2010 SteamCannon, JavaNight, Dec 2010: slides\nBoxGrinder, JUDCon Berlin, Oct 2010: slides\nCirrAS — JBoss w chmurkach, Javarsovia, Jul 2010, polish: slides\nStormGrind — Hackowanie w chmurkach, Silesia JUG, Apr 2010, polish: slides\n","permalink":"https://goldmann.pl/presentations/","summary":"\u003cp\u003eFrom time to time I’m attending various conferences. Sometimes I’m even a speaker. Below you can find list of presentations I gave so far.\u003c/p\u003e\n\u003ch2 id=\"license\"\u003eLicense\u003c/h2\u003e\n\u003cp\u003e\u003cimg alt=\"Creative Commons Attribution-ShareAlike 3.0\" loading=\"lazy\" src=\"https://i.creativecommons.org/l/by-sa/3.0/88x31.png\"\u003e\u003c/p\u003e\n\u003ch2 id=\"2014\"\u003e2014\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eDocker and JBoss — the perfect combination\u003c/strong\u003e, Toruń JUG, Oct 2014: \u003ca href=\"/presentations/2014-torun-jug-docker/2014-torun-jug-docker.pdf\"\u003eslides\u003c/a\u003e, \u003ca href=\"https://github.com/goldmann/goldmann.pl/tree/master/.presentations/2014-torun-jug-docker/demos\"\u003edemos\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eDocker and JBoss — the perfect combination\u003c/strong\u003e, JUGtoberFest 2014, Poznań, Oct 2014: \u003ca href=\"https://github.com/goldmann/goldmann.pl/tree/master/.presentations/2014-jugtoberfest-docker/\"\u003eslides\u003c/a\u003e, \u003ca href=\"https://github.com/goldmann/goldmann.pl/tree/master/.presentations/2014-jugtoberfest-docker/demos\"\u003edemos\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eRevolution in software distribution called Docker\u003c/strong\u003e, Y Soft: Technology Hour, Sep 2014: \u003ca href=\"/presentations/2014-ysoft-technology-hour-docker/2014-ysoft-technology-hour-docker.pdf\"\u003eslides\u003c/a\u003e, \u003ca href=\"https://github.com/goldmann/goldmann.pl/tree/master/.presentations/2014-ysoft-technology-hour-docker/demos\"\u003edemos\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eDocker and JBoss — the perfect combination\u003c/strong\u003e, Virtual JBoss User Group, Sep 2014: \u003ca href=\"https://www.youtube.com/watch?v=4uQ6gR_xZhE\"\u003erecording\u003c/a\u003e, \u003ca href=\"/presentations/2014-vjbug-docker/2014-vjbug-docker.pdf\"\u003eslides\u003c/a\u003e, \u003ca href=\"https://github.com/goldmann/goldmann.pl/tree/master/.presentations/2014-vjbug-docker/demos\"\u003edemos\u003c/a\u003e\u003c/p\u003e","title":"Presentations"},{"content":"There are several ways of contacting me.\nTwitter You can find me on Twitter. I’m @marekgoldmann.\nIRC I’m mgoldmann on irc.freenode.net. You can find me i.a. on the following channels:\n#fedora-cloud\n#jboss-docker\nRemember that I’m CEST timezone.\nIM I’m not very often on IM’s these days, but I have a Jabber/XMPP account: my_last_name@jid.pl.\nEmail You can send me an email to marek.MY_LAST_NAME@gmail.com.\n","permalink":"https://goldmann.pl/socially/","summary":"\u003cp\u003eThere are several ways of contacting me.\u003c/p\u003e\n\u003ch2 id=\"twitter\"\u003eTwitter\u003c/h2\u003e\n\u003cp\u003eYou can find me on \u003ca href=\"https://twitter.com/\"\u003eTwitter\u003c/a\u003e. I’m \u003ca href=\"https://twitter.com/marekgoldmann\"\u003e@marekgoldmann\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"irc\"\u003eIRC\u003c/h2\u003e\n\u003cp\u003eI’m \u003ccode\u003emgoldmann\u003c/code\u003e on \u003ca href=\"http://freenode.net/\"\u003eirc.freenode.net\u003c/a\u003e. You can find me i.a. on the following channels:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"irc://irc.freenode.net/fedora-cloud\"\u003e#fedora-cloud\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"irc://irc.freenode.net/jboss-docker\"\u003e#jboss-docker\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRemember that I’m \u003ca href=\"http://www.timeanddate.com/library/abbreviations/timezones/eu/cest.html\"\u003eCEST\u003c/a\u003e timezone.\u003c/p\u003e\n\u003ch2 id=\"im\"\u003eIM\u003c/h2\u003e\n\u003cp\u003eI’m not very often on IM’s these days, but I have a \u003ca href=\"http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol\"\u003eJabber/XMPP account\u003c/a\u003e: \u003ccode\u003emy_last_name@jid.pl\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"email\"\u003eEmail\u003c/h2\u003e\n\u003cp\u003eYou can send me an email to \u003ccode\u003emarek.MY_LAST_NAME@gmail.com\u003c/code\u003e.\u003c/p\u003e","title":"Socially"},{"content":"I’m a Software Engineer, mostly.\nWork I work for Red Hat. I’m there some kind of a plumber working in different areas including Cloud, Virtualization, Operating systems (Fedora), RPMs, Middleware (JBoss AS/EAP) and Polyglot. I’m part of project:odd.\nFor a few years I was the BoxGrinder project leader — a simple solution for creating virtual appliances for Cloud and many virtualization providers. Currently I’m busy helping with the TorqueBox project — a Ruby application server and packaging and maintaining WildFly/JBoss AS into Fedora.\nAnd yes - I have a GitHub profile.\nPresentations If I have the chance — I’m giving talks on conferences and not only.\nCV You can also look at my LinkedIn profile.\nOther things Some time ago I was pretty active in propagating open communication using XMPP protocol. I have my own public XMPP server — jid.pl.\nI am co-author of Hapi — a polish easy to use XMPP client.\n","permalink":"https://goldmann.pl/technically/","summary":"\u003cp\u003eI’m a Software Engineer, mostly.\u003c/p\u003e\n\u003ch2 id=\"work\"\u003eWork\u003c/h2\u003e\n\u003cp\u003eI work for \u003ca href=\"http://www.redhat.com/\"\u003eRed Hat\u003c/a\u003e. I’m there some kind of a plumber working in different areas including Cloud, Virtualization, Operating systems (Fedora), RPMs, Middleware (JBoss AS/EAP) and Polyglot. I’m part of \u003ca href=\"http://projectodd.org/:\"\u003eproject:odd\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eFor a few years I was the \u003ca href=\"https://web.archive.org/web/20170814223540/http://boxgrinder.org/\"\u003eBoxGrinder\u003c/a\u003e project leader — a simple solution for creating virtual appliances for Cloud and many virtualization providers. Currently I’m busy helping with the \u003ca href=\"http://torquebox.org/\"\u003eTorqueBox\u003c/a\u003e project — a Ruby application server and packaging and maintaining WildFly/JBoss AS into Fedora.\u003c/p\u003e","title":"Technically"}]