In our server architecture, we have a preprod and production server. We realized the production server containerd and the preprod versions are not the same. It falls in a version that had a known bug. Since then, a new version was released that fixed this issue. Our problem is that (idealy) we would like to keep the services running.
Is that possible? I can't find any documentation or procedure in the official documentations, the only thing I found was this question, but it's from 6 years ago.
Any new light on this would be really appreciated.
Related
I am trying to modify an existing installation of Elasticsearch (I believe it's version 2.3.0) running on Docker. Most of the information I'm finding online is for newer versions of Elasticsearch, but I'm hoping to avoid having to update the whole thing.
I need to restrict access to Elasticsearch for security reasons. I'm trying to set a password, but so far I haven't had any luck. Most of the tutorials I've found (apart from being about later version of Elasticsearch) talk about using X-Pack, but I don't think this is installed in the docker container. Is it necessary to install X-Pack, or is there another way?
2.3 is super old, there was no security back then and was only added in 5.6
you will need to use something like nginx to manage, or ideally, upgrade to a supported version. Security is free these days as well
This would be on an AWS server. I have not been able to find a single guide that will walk me through this.
One of these guides was promising, up until the point where I was asked to do:
wget https://raw.githubusercontent.com/puma/puma/master/tools/jungle/init.d/puma
wget https://raw.githubusercontent.com/puma/puma/master/tools/jungle/init.d/run-puma
But neither of these repos seem to exist. I realize this is not a programming question, but I am trying to switch from Passenger, to what Rails is supposed to be using natively, but I can't really find much information about deploying to a production environment.
Well
6 month ago the good person answered as a comment on Rails Server with Apache + Puma (via reverse proxy)
I'm sure that you have solved the problem already, but for anyone else coming here in the future, using init.d has been deprecated in favour of systemd (starting with version 5 of puma).
The init scripts that you mentioned are still available. Go to the project on GitHub, and select the most recent 4.x branch. Under tools, you will find the last release of the files.
I've been asked to research Docker. The question that I cannot get a definitive response to is "can you run Docker on Windows in production?".
I keep seeing "Docker image containers can run natively on Linux and Windows. However, Windows images can run
only on Windows hosts and Linux images can run only on Linux hosts, meaning a host server or a VM."
I'm not interested in running containerized windows applications (.net). We have Spring Boot (java) applications & are creating a microservices architecture. These containerized apps. don't need an OS running in the same container.
We also need an orchestration engine like Kubernetes and its unclear if this is something that can run in production on windows either.
I've been fighting the good fight trying to get deployment environments switched to Linux but that's a loosing battle at this point.
Citing the docs:
Welcome to Docker for Windows!
Docker is a full development platform for creating containerized apps,
and Docker for Windows is the best way to get started with Docker on
Windows systems.
Take this literally. It's meant by the vendor as a dev tool to develop your Docker environment on Windows, not a production environment. To run it in production, they expect a Linux host.
It's not clear if the OP is asking "Can I run Docker on Windows in production" (like from a licensing perspective), or "should I run it" (like from an experience perspective.) I have an answer that should address both points.
It's indeed interesting to note first that as I write this, all the answers and comments so far are from 2018 or (like the question) 2017.
Here's at least one 2019 post on the topic from Docker (including listing clients running in production, so it addresses both points):
https://www.docker.com/blog/5-reasons-to-containerize-production-windows-apps-on-docker-enterprise/
And while the title refers to Docker Enterprise, the article does say "Hundreds of enterprises now run Windows container nodes in production", without that Enterprise caveat.
Even so, folks who may "not want to pay to run Docker Enterprise" should note that Windows 2016 and 2019 include a license of Docker Enterprise, free. (As for the recent upheaval of Docker where the Enterprise product was sold to Mirantis, there's no indication yet that will change the included Windows licensing of it.)
Still, I realize that the OP and other readers may seek still more (documented) evidence of production Docker deployment on Windows. I'll leave that for others to elaborate. Just didn't think this should stand here without anything more recent than July 2018.
Check out this blog, it quotes "Windows Server 2016 is the where Docker Windows containers should be deployed for production".
First of all, I suspect this question is rather stale after 3 years. I don't know if you are still struggling with the problem, I would love to hear your experience and the route you had taken.
This is probably a biased answer but I will try to answer with my experience. Like you, we have also lost the good fight to persuade our client to use a Linux server. We have 2 metals and a small bunch of virtual machines running Windows Server 2019 - Server version 1809 (Which is not the cutting edge, but the most recent stable version) It was indeed an improvement on top of WS2016. However it still had some problems. The major problem was with the docker swarm. The overlay networking with routing mesh was not working properly. So we had to fall back to containers with docker-compose and manual service discovery, which kinda beats the purpose of docker.
That being said, the problem with the Swarm network could be because of the fact that we are using virtual machines and Hyper-v switches. On top of that, we had no direct access to host network and we had to jump through some bureaucratic hoops whenever we require changes in the network, which got super old super fast when we want to test stuff. Additionally, we did not have Active Directory because of our lack of confidence to network. I am still not sure if DCs would play with docker in a virtual environment. Still not having AD was manageable since we did not have many machines.
Another problem was that we did not have nested virtualization (i.e. cannot run moby) due to CPU issues, and WSL2 with support for Docker is not available on WS19 LTSC editions. So I had to write our own images for many stuff that we use. Like Jenkins, Redis, etc. You can find the dockerfiles here if interested But obviously keeping them up to date and tidy was a huge work and I did not have much time to invest.
Performance-wise, we seemed to have no issues but we did not really make a comparative analysis.
All in all, I love Docker, it is a great product. But after this project I am thinking not to touch Docker on windows in a production environment with a 10 foot pole. In fact, I don't know if I will ever use a Windows machine as production environment in the future. It is cool to have it in development though.
My understanding is that Containers on Windows Server should be fine for production while Containers on Windows Desktop should be only for dev and test, not production. I saw one post "MICROSOFT SOFTWARE SUPPLEMENTAL LICENSE FOR WINDOWS CONTAINER BASE IMAGE" https://learn.microsoft.com/en-us/virtualization/windowscontainers/images-eula, not sure how this one is related to this question?
I can highly recommend not to use Docker Desktop for Windows in Production.
The host machines (Windows 10 Pro) where configured to restart everyday at a certain time and the Docker Container where Linux containers which as recommended where using the WSL2 based engine.
I was testing it on 20 devices for a over one year now and from 20 Pc's had at least 5 now the problem that Docker Desktop cannot be initialized. Which means that Docker Desktop is not starting anymore until you remove some folder(s) in %APPDATA% but when you do so it worked only 3 out of 5 times for me that Docker Desktop was able to start after that. One time needed to reinstall Docker Desktop the remaining One I needed to reload all the docker images and configure them again. Most of the issues seemed to have been a result of a power cut.
Most annoying are the updates from my perspective, because from one to the other version all images and running containers where gone and I needed to reconfigure them, happend with 2 Version in the past but not on all computer.
The Linux machines on the other hand no issues.
I found the possibility to create a windows service with a Wildfly 9.0.1 Final. But my question is more how can I create an automatic service out of this?
I like to have this on installation time, instead of doing this manually. My expertise on this is not that good, and don't find anything on my search results.
Kr
So, there I fix my problem of 2 days figuring out how it works.
By bad for all the persons looking for the same answer.
JBoss Wildfly the procrun from Apache.
So in the script of Wildfly I added the --Startup=auto and then the service was installed as an automatic service
I have had a Rails 3 app deployed on Elastic Beanstalk for close to 2 years now. For the most part, I haven't had any issues; however, I recently upgraded to one of their new Ruby configurations (64bit Amazon Linux 2014.09 v1.0.9 running Ruby 2.1 (Passenger Standalone)) and I've been fighting an issue for several days where one of more Ruby processes will consume the CPU - to the point where my site becomes unresponsive. I was using a single m3.medium instance, but I've since moved to a m3.large, which only buys me some time to manually log into the EC2 instance and kill the run away process(es). I would say this happens once or twice a day.
The only thing I had an issue with when moving to the new Ruby config was that I had to add the following to my .ebextensions folder so Nokogiri could install (w/bundle install)...
commands:
build_nokogiri:
command: "bundle config build.nokogiri --use-system-libraries"
I don't think this would cause these hanging processes, but I could be wrong. I also don't want to rule out something unrelated to the Elastic Beanstalk upgrade, but I can't thing of any other significant change that would cause this problem. I realize this isn't a whole lot of information, but has anyone experienced anything similar to this? Anyone have suggestions for tracing these processes to their root cause?
Thanks in advance!
Since you upgraded your beanstalk configuration, I guess you also upgraded Ruby/Rails version. This bumped up all gem versions. The performance issue probably originate from one of these changes (and not the Hardware change).
So this brings us into the domain of RoR performance troubleshooting:
1. Check the beanstalk logs for errors. If you're lucky you'll find a configuration issue this way. give it an hour.
2. Assuming all well there, try to setup the exact same version on your localhost (passenger + ruby 2.1 + gems version). If you're lucky, you will witness the same slowness and be able to debug.
3. If you'd like to shoot straight for production debugging, I suggest you'd install newrelic (or any other application monitoring tool) and then drill into the details of the slowness in their dashboard. I found it extremely useful.
I was able to resolve my run away Ruby process issue by SSHing into my EC2 instance and installing/running gdb. Here's a link - http://isotope11.com/blog/getting-a-ruby-backtrace-from-gnu-debugger with the steps I followed. I did have to sudo yum install gdb before.
gdb uncovered an infinite loop in a section of my code that was looping through days in a date range.