I have installed and configured a custom Laravel private repository hosted on bitbucket on minishift running on my laptop. I found that all the files were imported properly without any issues and the image is running.
However, now I want to make configuration changes in my repository for my application to work. How do I make it?
Will I have to import the image from VM on my laptop, work on them
and then push the changes back
Or will I be able to access the files or folder from within my editor or IDE?
I am new to Openshift origin and using it for the first time.
If you have your source code on Bitbucket, you would checkout the repository to your local laptop, make the changes, commit them, and push them back to the repository on Bitbucket. You would then tell OpenShift to rebuild the application by clicking on the Start Build button on the build configuration details in the web console, or by using oc start-build on the command line, supplying it the name of the build configuration to do the build for. The rebuilding of the image from the code when done will automatically trigger a new deployment. If you set up a webhook in Bitbucket, you can have it tell OpenShift when new changes have been pushed and that will trigger a build without you needing to do it manually.
If you are quite new, I would suggest you work through the interactive tutorials at:
https://learn.openshift.com
Also read the free eBook on OpenShift.
https://www.openshift.com/promotions/for-developers.html
Related
I've set up PhpStorm to auto-deploy changed files to the vagrant box.
However, I run the build scripts in the box, and I can't count the times I shipped some module without copying back (downloading) those compressed JavaScript files, out of vagrant, into my local working directory.
Is there a way to make PhpStorm monitor the deployment server, and download changed files?
Is there a way to make PhpStorm monitor the deployment server, and download changed files?
There is no auto-download.
The IDE is build around "local code first" idea where local is the source and any remote is just a copy.
If you need to download remote stuff I suggest to manually use Sync With Deployed action from Deployment menu: it allows to manually sync files and folders both ways: https://www.jetbrains.com/help/phpstorm/deploying-applications.html
https://youtrack.jetbrains.com/issue/WI-1284 I guess (as it's about syncing remote to local)... Watch this ticket (star/vote/comment) to get notified on any progress.
I have a simple source-to-image deployment in Openshift (some webpage with HTML and Javascript). The deployment was built from an Apache template, fetching code from a repository in GitLab.
Now there is a new release of the webpage at GitLab that must be deployed. I tried to redeploy, but Openshift fetches again the commit initially deployed, not the HEAD. How can I force Openshift to fetch the HEAD of the repository?
The trick here is to do a re-build, instead of a re-deploy. Only the re-build fetches the most recent source from the repository. One must go to Builds > Builds, select the one corresponding to the deployment and then click on the Start Build button:
I am trying to move an old Wordpress install to Openshift.
So I setup two gears, one running MySQL (Gear #1) and the other is setup to be a scalable PHP5 gear (Gear #2). I have manually restored the database data to Gear #1 and manually restored original Wordpress files in Gear #2 under ~/app-root/runtime/repo. The app is running fine now with everything in place.
However, when I try to raise the max number of scalable PHP5 gears from 1 to 2, the app stopped working and showing only the default gear landing page, just like what an empty gear would show. Setting maximum scalable gears back to 1 then the app would work again.
Is it true that the Wordpress files (or any other PHP or web files under ~/app-root/runtime/repo) must be checked in with Git in Gear #2, in order for scaling up to Gear #3+ to work properly? If so, is there anyway I can check-in the files that I already have in Gear #2 from within itself? If not, how can I check-in the set of files that I already have from the old Wordpress install?
Thank you for your help in advance!
Cheers,
KC
If you want to get the files on your web gear into git you have two options:
1.) SSH or SFTP into your gear and copy the files to your local workstation, then clone your git repo to your local machine, and copy the files into it, git commit & git push. Then your files will be deployed properly.
2.) SSH into your gear, initialize a git repo in your app-root/repo folder, and then setup your git repo in that gear (the one openshift created) as a remote and add/commit/push your files, then you can do a clone on your local workstation and a push and everything should deploy correctly.
I spoke with operations about this:
We do an rsync from the app-deployments directory, which are the files that were in git. So it does seem at this point that git must be used for scaled applications to work correctly. Please add your use case to http://openshift.com/ideas
Hi I am new to open shift . I don't know how to create repository and deploying our project to it. I have configured it through command prompt. After installing rhc successfully through command prompt I am getting confusion of help given on Open Shift site regarding uploading the application not about pushing and commiting. I got the idea about commiting and pushing but I did not get the idea about deploying or uploading the application first time . Please help me I am getting stuck for a lot of time thanks in advance
Deploying and Building Application
All OpenShift applications are built around a Git source control workflow - you code locally, then push your changes to the server. The server then runs a number of hooks to build and configure your application, and finally restarts your application. Optionally, applications can elect to be built using Jenkins, or run using "hot deployment" which speeds up the deployment of code to OpenShift.
Making Changes to your Application
As a developer on OpenShift, you make code changes on your local machine, check those changes in locally, and then "push" those changes to OpenShift. One of the primary advantages of Git is that it does not require a continuous online presence in order to run. You can easily check in (in Git terminology, 'commit') and revert changes locally before deciding to upload those changes to OpenShift.
Every OpenShift application you create has its own Git repository that only you can access. If you create your application from the command line, rhc will automatically download a copy of that repository (Git calls this 'cloning') to your local system. If you create an application from the web console, you'll need to tell Git to clone the repository. Find the Git URL from the application page, and then run:
$ git clone <git_url> <directory to create>
Once you make changes, you'll need to 'add' and 'commit' those changes - 'add' tells Git that a file or set of files will become part of a larger check in, and 'commit' completes the check in. Git requires that each commit have a message to describe it.
$ git add .
$ git commit -m "A checkin to my application"
Finally, you're ready to send your changes to your application - you'll 'push' these changes with:
$ git push
The output of the push command will contain information from OpenShift about your deployment -
Source Click me
There are two options for deploying content to the Tomcat Server within OpenShift. Both options
can be used together (i.e. build one archive from source and others pre-built)
1) (Preferred) You can upload your content in a Maven src structure as is this sample project and on
git push have the application built and deployed. For this to work you'll need your pom.xml at the
root of your repository and a maven-war-plugin like in this sample to move the output from the build
to the webapps directory. By default the warName is ROOT within pom.xml. This will cause the
webapp contents to be rendered at http://app_name-namespace.rhcloud.com/. If you change the warName in
pom.xml to app_name, your base url would then become http://app_name-namespace.rhcloud.com/app_name.
Note: If you are building locally you'll also want to add any output wars under webapps
from the build to your .gitignore file.
Note: If you are running scaled EWS2.0 then you need an application deployed to the root context (i.e.
http://app_name-namespace.rhcloud.com/) for the HAProxy load-balancer to recognize that the EWS2.0 instance
is active.
or
2) You can git push pre-built wars into webapps/. To do this
with the default repo you'll want to first run 'git rm -r src/ pom.xml' from the root of your repo.
Basic workflows for deploying pre-built content (each operation will require associated git add/commit/push operations to take effect):
A) Add new zipped content and deploy it:
cp target/example.war webapps/
B) Undeploy currently deployed content:
git rm webapps/example.war
C) Replace currently deployed zipped content with a new version and deploy it:
cp target/example.war webapps/
Note: You can get the information in the uri above from running 'rhc domain show'
If you have already committed large files to your git repo, you rewrite or reset the history of those files in git
to an earlier point in time and then 'git push --force' to apply those changes on the remote OpenShift server. A
git gc on the remote OpenShift repo can be forced with (Note: tidy also does other cleanup including clearing log
files and tmp dirs):
rhc app tidy -a appname
Whether you choose option 1) or 2) the end result will be the application
deployed into the webapps directory. The webapps directory in the
Tomcat distribution is the location end users can place
their deployment content (e.g. war, ear, jar, sar files) to have it
automatically deployed into the server runtime.
Here is really good tutorial prepared by openshift guys with source code so you can go wrong with it.
https://www.openshift.com/blogs/spring-polyglot-persistence-part-1
To sum up - if you have your application on some repository just create your application so it creates folder with git repo in your directory
rhc app create notebook jbossas-7 -l <openshift_login_email> -d
Go to newly created directory and replace default openshift code with your repo
git rm -rf src/ pom.xml
git commit -am "removed default files"
git remote add notebook -m master git://github.com/shekhargulati/notebook-part1.git
git pull -s recursive -X theirs notebook master
git push
You should see your java application build.
What application type is your app? Java/PHP/Python...? If it is a PHP based app, then externally exposed PHP code should go into "php" directory. Whenever you create an application using the rhc commands, a local repository is created, inside which you will find a README document, which lists your deployment steps. Additionally, you can refer to OpenShift user guide here:
https://www.openshift.com/sites/default/files/documents/OpenShift-2.0-User_Guide-en-US_5.pdf
I am using Jenkins for our build server. I have multiple projects using the same Mercurial (Hg) repository and want to avoid each project cloning it's own local repo to build from (since the repo is rather large). This is supposed to be possible via Jenkins and the Mercurial plugin.
In my Mercurial plugin configuration I have checked both "Use Repository Caches" and "Use Repository Sharing". In each project, the same repository location (a network location specified via IP address) is listed.
However, each project still seems to want to create a clone of the repository. Any ideas?
In our setup (using Jenkins 1.506), I've defined a custom workspace under the Advanced Project Options for each of my builds, typically at [project]\repo and then build from there into a \build\ folder.
If you define the custom workspace for each Jenkins project to point to the same shared custom workspace using the same source for the repo it will reuse what is already there.
I've not tested this, but I would assume that under this setup, it is important to prevent concurrent builds from occurring in the same working directory. Bad things would follow.
As a followup question: What is your rationale for not wanting each build to have its own source code?