I have been looking at Openshift docs and on Stack Overflow for a while now and I can't seem to get any answers.
I want to know what the standard pattern is for developing applications for deployment on Openshift? I am especially concerned with testing of action_hooks prior to deployment. I found this particularly troublesome when I was using a DIY cartridge recently where I had to deal with downloading dependencies in my build script prior to starting my application. As my application kept failing to start every time I made a change and pushed it (I only did this as an initial test of the Openshift service, I would never develop like this). I ended up having to ssh onto my instance and resolve the issue by trial and error (not really ideal).
I appreciate any help anyone can offer.
Thanks
The only way that I am aware of to test action hooks on OpenShift is to ssh into an application and run them manually from the command line. This way you can quickly debug & update them. Then copy them to your git repository and do a git push to deploy the new code.
The only other way I can think of would be to run OpenShift Origin (v2) locally and use that to test with.
Related
I have inherited a Read The Docs in-house installation (to see our internal git server), in which it was a known issue that the build volume would eventually run full. Now it has again and we would like to find the proper solution. We currently run in Openshift and to my understanding the build job runs "next to" the web server and communicate through shared volumes, including a build volume.
It appears that the problem is that old builds (notably Pull Requests) are not deleted but stay for ever on the build volume. I am not a Django programmer so I am unfamiliar with these kind of applications making the spelunking challenging.
Is this a simple setting about cleaning that my ex-colleague have missed, or where should I look in the sources? The last thing he did before leaving was upgrading to 6.0.
I've just learnt about GitHub Actions and I think it's super fantastic.
One thing that struck me hard at the beginning was, when I was setting up the self-hosted runner, GitHub asks me to run a bunch of command on my local machine which apparently is in private network and it's not exposed to the internet (inbound - meaning the www cannot reach it).
However, after installing what GitHub asks me to install, it seems like a webhook is set up successfully and every time there's push/merge to my master (set up in GitHub action file), the worker from my computer knows and start pulling the newest version of the repo and start installing dependencies and other CI/CD stuff.
Now what I'm curious is how does GitHub actually talks to my VM while it's in a private network?
I've never been a networking guy, so I'm not so sure why this is possible. But it's fascinating.
It's not that GitHub is connecting to your self-hosted runner (inbound) but the self-hosted runner itself connecting to GitHub (outbound). This is why it works. It's your VM (with the runner in the private network) talking to GitHub. The communication direction is reversed. After your self-hosted runner connects to GitHub, both parties keep the connection open. That allows all the events to be pushed to your runner through the connection by the GitHub repository if something happens (PR is opened, a commit was made, etc...). The connection remains open while the runner is operating. Of course, if something bad happens to the network and the connection is broken the communication will stop working. To fix that the runner periodically sends ping packets to GitHub to validate the connection is working and attempts to reconnect if it's not.
You can read more about the communication workflow in the official documentation.
Is there a way to migrate a server application (with its repository), to the new Next Gen Console?
I have already a WildFly server in my personal account at URL: https://openshift.redhat.com/app/console/applications
But when I open the Next Gen Console, it's empty, and suggest me to create new project with a new server.
https://console.preview.openshift.com/console/
Is there a way to avoid setting up everything again?
I would like to keep server configurations, git repository, and Jenkins app from my former OpenShift Web Console.
Sorry, there is no direct migration tool. The manner in which the systems works is quite different from an operational standpoint, but you are also potentially going to have to tweak how your application code is organised and configured. I would suggest you create a fresh application in the new version to learn more how they are different and then you can plan what you may need to do to migrate it. I would suggest making using of the Google Group for OpenShift if you have more questions as it provides a better forum for discussion.
https://groups.google.com/forum/#!forum/openshift
I am trying to get an application running on OpenShift but after trying to create an ssh key on Ubuntu using ssh-keygen I ran into permissions problems. This is because I find I have no need for the rhc client if it only automates this process but bloats my computer (laptop) with a ruby installation.
I find that it would be best to have an alternative for Ubuntu (Linux) users. Is it possible to make this happen or do I have to go the rhc way?
You get a long way without the rhc command line tool. Obviously you can create your ssh key yourself and add/mange it via the OpenShift website. You can also create your application there and add cartridges. When it comes to starting the app, you can usually do that by jsut pushing your git repository. Last but not least, you can ssh onto your OpenShift gear and do a lot from there, for example view the log files.
That said, the rhc client is your one stop client for all this (and more). So even if you might not need it right now and some task are in fact done easier without it, I would still recommend to install it. A lot of information/tutorials are using rhc and w/o enough experience you will not know how to achieve a certain task in a different way.
I have bit of experience in running a simple build upon every SVN commit (it is a piece of cake)
Regarding deployment of the war to a remote production server via
Hudson, there seem to be some alternatives:
use the 'deploy' target in the app's build.xml
use the deploy-plugin of Hudson
which I fail to get working :(
What is the simplest way to do a remote deployment to Tomcat?
Are there any examples available?
And what about release management? How do we tag our releases in
your SCM?
I use Maven for builds.
Since I am working with WAS I use the WAS Builder Plugin for deployment. However, I could also just fire up a batch/shell script for deployment. My current approach is to use slaves that run on the target machine where I want to deploy and assign my deployment jobs to them.
For tagging you can use whatever you prefer. The are 3 basic options:
Let maven do it
run a command line command
use a Hudson plugin
We use subversion, so the Subversion Tagging Plugin would be a natural match. However, we don't use Hudson for tagging right now. However, there are several plugins out there for different SCMs. I usually prefer a plugin over a command line, one reason is that company policy forbids to store passwords unencrypted and it is usually fairly easy to configure.
Our strategy has been to combine the promoted builds plugin and the deploy plugin in hudson. Then, when something is "promoted," send an email and do the deployment. The deployment plugin is cargo based and works with a variety of web and app servers.
Maybe post a little info about why the deploy plugin isn't working for you?