Using IBM Websphere Liberty Docker Image in production - websphere-liberty

There are two images available on Docker Hub for IBM Websphere liberty.
https://hub.docker.com/_/websphere-liberty/
https://hub.docker.com/r/ibmcom/websphere-liberty/
To use the 1st image in a production environment, the licensing process is explained in https://github.com/WASdev/ci.docker/tree/master/ga/production-upgrade
But to use the 2nd image in production, no such reference is found. Requesting for some pointers here.

As illustrated in the GitHub repo you mentioned, either of these sets of images can be used in production as-is, as long as you have the proper entitlement.
If you want to apply a license to either of them, please see this page which outlines the steps you can take to create a new image with the license applied.

Related

Migrating From Digital Ocean to Heroku

I have an app that uses Flash, MariaDB, and Python which I currently host on Digital Ocean. I am planning to move to Heroku for scalability purposes, but I am unable to find any resources online talking about the process of migrating data from Digital Ocean to Heroku. Can anyone explain the process? Thanks
Heroku provides Dynos (application runtime) and Add-Ons (databases and other tools).
First create a Dyno (it can also be free) and deploy your Python application (you can push the code from Git or create a Docker image for the Heroku Docker Registry).
Then enable the MariaDB add-on to setup your storage (there is a free plan here too, check if this is suitable in your case).
You need to provide the MariaDB connection string as environment variable, this is explained here
Finally it is a good idea to use Config Vars for all environment variables that your application might need (ie tokens, secrets).

Jelastic: how to contribute to Certified App source code?

while setting up a basic 1 x NGINX load-balancer in front of 2 backends, I ended up in what it is clear to me to be a bug: the cron of this Certified App cannot be edited:
As you can see, in this particular App the cron file is owned by root:root and doesn't have the extended attribute (the plus on the right of permissions) necessary for the file to be edited also by the logged in user (nginx in this case).
All other certified apps allow instead the main login user to have crontabs, even though I found the permissions of each file vary a lot.
I've stumbled on https://github.com/jelastic/jem/blob/master/etc/jelastic/export.conf and it seems the file to go for proposing a bugfix, but it's last update if Aug-2016, so I guess Jelastic had closed much of its source code.
How can we contribute to Certified App source code?
indeed it is a bug as cron file of nginx user isn't editable in a balancer template, by design in has to be.
As for exports.conf - this file left for backwards comparability, but no more used.
The problem will be definitely fixed in latest templates, as for existing containers - we would like to apply a patch to fix them, if you provide us more details about hosting service provider you are using - we will help with that.
As for contribution to certified templates, all the images are publicly available on Docker Hub, you can create your own version of template based on existing one if you build a docker image and in your Dockerfile you specify
"from jelastic/nginxbalancer" as a base, then you can do any modifications to the filesystem. Next step will be just to replace existing balancer with your custom one.
Anyway, let's start with fix of existing containers.
Many thanks for finding out the bug!

Bluemix and CMS (Joomla) and CF Push

I have installed a Joomla site with CF on bluemix.
As you know Joomla as other CMS allows to install components for adding functionalities.
This uploads the php code needed for the component and add additional tables/entries in the Database.
My issue is that when I CF PUSH, the new component script is removed from the joomla folders on bluemix, and the database still contains component's tables/entries.
I guess this is the situation for all CMS (Drupal, Wordpress, Joomla, Vbulletin, etc..).
How could I get a kind of CF PULL (?) to keep the modified CMS code including the new component locally on the computer side ?
So when i will redo the CF PUSH the installed component will not be erased.
Thank you in advance for your support,
Best regards
Yves
There is no cf pull command in Cloud Foundry. The closest you would have is the cf files app-name command that you can navigate the directory structure of your cloud application and get specific files as needed, but this would be really tedious if you have multiple files to copy to your local computer.
It looks like Joomla fits better with the IBM Containers service in Bluemix. With the IBM Containers you can have an Docker image from Joomla (https://hub.docker.com/_/joomla/) and use persistent Volumes to save your added functionality. You can also use any Bluemix services (like a database) with IBM Containers.
The article below provides more details and step by step instructions to create an IBM Container for Wordpress. You can easily modify it for Joomla:
http://blog.ibmjstart.net/2015/05/22/wordpress-on-bluemix-containers/
When you push an application on a runtime, php Java or whatever, it will restage all the application sources, included what has been configured and modified before through the cms interface, leaving the db databases untouched. And it is for joomla, but also for drupal or WP or any other cms. By this way to achieve what you wish you have 3 options:
- push exactly the filesystem structure you need on Bluemix, including the configuration files and modules to use on it
- use (as suggested above) a container instead of a runtime: anyway also with a container you have to install your cms on an external docker volume, otherwise the cms will be reset every time you restart the container
- use a Bluemix VM

A good strategy for knowing the versions of deployed applications?

In order to know which revision number the application is built from, we use to give the ears we deploy to Glassfish names like myapp_2012-01-20_rev22123.ear. Then we can simply login to Glassfish and see what version is deployed in the web interface (as the appname is the name of the ear file). A downside of this approach is that we need to do a manual undeploy/redeploy to update the name...
But I would like to script the undeploy/deploy process, and having each version of an ear get a different name is not very suitable to scripting this redeployment process. Glassfish 2 does not support the "list applications" goal that Glassfish 3 has, which I could have used to retrieve the application name to undeploy.
So is there any good strategy that will easily allow us to see what version is deployed of an application, and that does not suffer from the above fault?
It would be preferable if this meant we did not have to change the existing applications (like add a jsp page or something to show the current scm revision), but a change in a Maven build script would be acceptable.
I faced a similar issue, I finally came around it by using maven-buildnumber-plugin and writing a simple servlet to get build information. You can find the details in the blog post I made.
Why not use the built-in GlassFish Server versioning to assign a version number at deploy time? This will also enable you to rollback to prior versions. For example:
asadmin deploy --name MyApplication:2012-01-20_rev22123 MyApplication.ear
There is more information on application versioning here:
http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv
Hope this helps.

Setting up a collaborative environment for web application development

My office is growing and ive been tasked to build out the IT for our web development.
Whats the best tool/setup for doing web development in a group setting? The requirements are a centralized code repository, a location to test development code on, and finally a way to push tagged code out to a staging server. What im thinking is svn/redmine for code repo, each user has an account on a central development machine to allow for ssh access(eclipse over ssh) and their own virtual host on the dev server which gives everyone a centralized development sandbox. Code is written and tested on this dev box then checked back into svn and later tagged and pushed out to the staging server. Yeah? Thoughts comments or recommendations?
*Also, in a dev environment what is the best way to handle databases? Is it wise to pull from the production database? Also should each developer have his/her own db or work off a master db?
**We are building a magento application and also have some custom backoffice tools that run on cakePHP.
Although this subject is off-topic in StackOverflow and flagged so then you need to concentrate on following areas:
VERSION-CONTROL
GIT has all the glory and you don't need your own box for this as https://bitbucket.org/ offers unlimited data and private/public repos and you can set your codebase there. http://github.com is also powerful and de facto most popular version-control oriented tool out there although it comes for a small price
so your master branches live in your version control and your devs will checkout frpom there and commit to it as well
your deployment tools will deploy data to your live and staging environments from your master
ENVIRONMENTS
usually three are used LIVE, STAGE, DEV
LIVE is well live and only approved code gets deployed there
STAGE is pre-live environment and should be exact replica environment according to LIVE so all things can be tested there by merchant
DEV is cool to have exact replica but can as well be on developers local env and is ment for loose testing and experimenting
DATABASES AND DEPLOYMENT
mysql databases are pain in the ass to sync so you better have a script for it that syncs from live to others and prevent syncing from other environments to LIVE. This limitation also requires that all the configuration and content will be added from LIVE only and only then synced down the line. Every change to schema or permanent setting should be handled by update scripts (As we are talking MAGENTO CE , MAGENTO EE has migration built in)
for deployment I also suggest you to build a fabric or capistrano script that resets dev and staging environments, handles database reset and pull from LIVE DB, and imports code from central repository.
it's also a good idea to target the following everyday tasks:
clients needs to reset the stage for it's tests
project manager, developer or testers need to test so spawning a test clone should be oneclick action (take current db and code and make it live in some subfolder for specific test only) as well as deleting the test
3rd party devs might need access to specific test or dev environment (this is actual with magento as in average there are at least 10 external extensions installed in every magento store)

Resources