Local vs remote installation question

I have an elementary question about how deployment works. Let’s say we are developing a project locally (Spring, Java, Maven, git) and want to have the updated version deployed on a remote server whenever updates are pushed to the project’s github repo.

Are there two possible approaches? (1) local Jenkins uses SSH to gain access to remote server and pushes content, (2) remote Jenkins pulls content from the github repo? Or is only one of the two recommended?

The tutorial I am working through shows how to install Jenkins locally, not remotely. But if we do this, how does the github repo message/trigger the local Jenkins to act, given the url “localhost:8080” (dynamic IP)?

I also installed Jenkins on my remote Ubuntu server, but am confronted with a different issue. The port, 8080 not accessible via https (afaik), and it seems to me that configuring system level stuff like agents over Jenkins could be hazardous if there is any eavesdropping.

I would very much appreciate advice as to which of these two paths I should take, and some words (or basic plan) on how the associated issues that I listed are dealt with.

FWIW, I’ve been using Jetty9 as my remote web-server. I’m open to changing to another web-server if that would help matters.

1 Like

I’ve been making progress with a tutorial aimed at beginners.
Jenkins Tutorial is For Beginners, DevOps and Software Developers

I’ve just covered the section on issuing Maven commands from Jenkins, about 2 hours in. It’s looking like the normal course is to set up Jenkins on the remote server. The Jenkins there can be set to respond to a URL trigger issued from the github repository on the push action. AFAIK, this trigger URL is perfectly fine being listened for on a high-numbered port like 8080.

The more crucial aspect will be setting up the remote Jenkins to engage with the github repo securely. I’m anticipating the tutorial will eventually get to covering these security issues (it’s 4 hours long).

In general people use a single centralized Jenkins server (might have multiple for scale or credential scoping reasons)

The only reason the install needs to be externally accessible is a) you want external people to access it and/or b) you want your SCM server to send Jenkins a notification when new code is available. You can always tell Jenkins to poll for new changes, its just less instant.

As for deployment, it’s better to figure out how to deploy without Jenkins, then automate doing that

If you deploy via like Capistrano or anisible, you can make Jenkins run that. There’s tooling like octopus deploy. Or like tomcat that has its own API. For Jenkins.io we build the site then deploy to azure blob and netlify.

Thank you for taking the time to reply! For a beginner, it’s so helpful get perspectives from people that active work with these tools. My position is that of a solo developer (MS Access database & Java “hobby” projects) hoping to break into some role in Java full-stack or back-end, working on small-scale projects using Spring Boot, as a way to “pull myself up by my bootstraps” to gain experience and skills.

My motivation for using Jenkins is motivated by seeing it frequently listed as a job requirement. I’ve also heard that if a junior java developer is taken on, the most usual thing is for them to be trained on an existing CI/CD infrastructure, rather than being asked to set up or modify the CI/CD. But given the level of competition for getting hired at the junior level (many more applicants per position than the hiring situation for experienced devs), I thought getting some hands-on might prove helpful, as well as provide a better understanding about the components of the chain. Of particular concern is getting a solid grip on all the security-related steps.

Getting Jenkins involved in my current workflow (solo dev using STS4 and git, deploying to remote server) would perhaps make some testing and deployment steps for my projects a bit less of a nuisance, but this would be more a side benefit, compared to gaining more insight into how the various components interact.

I’ve just come across slave nodes in the tutorial (3-hour point in the video). This looks like the best bet! I see setting up a “jenkins” user on my remote server and setting up a credentialed login for that user.

Reality-check feedback is always much appreciated!

@philfrei – I’m in the same situation – thanks for sharing your reasons for learning the tool. (I’m learning AWS and setting up some infrastructure using the “free tier” for the same reason – it shows up as a desired skill on so many job applications, although so does Azure, etc.)

I’m wondering if you finished the Jenkins tutorial, found it useful, moved on to a more advanced course, etc.? Any other recommendations? Thanks.

Hi Joseph -

Yes, I finished the Jenkins tutorial that I linked. Yes, it was super useful. I think “real engineers” might find the tutorial a bit slow (some indicate this in the comments), but as someone coming in cold, I really appreciated the pace and explanations given along the way. It is getting a little stale, but is still current enough to be really helpful.

At this point, I have Jenkins running locally on the same Ubuntu-OS PC where I do Spring Development. As part of my workflow, I first push the work (I’m working in a git clone) to github, using STS4/Eclipse plugin provided for this.

Then, I open Jenkins and run a workflow which does the following: clones the github project it to my remote site (I’m using a shared remote server from linode for $5/mo), builds and deploys the project.

I don’t know exactly how much time it saves (it’s slow to complete), but the effort it saves to have this automated feels great, to just hit one button and not worry about PAT to github, my remote server, firing up ftp & putty, and executing numerous mvn and bash commands along the way.

I stopped there with Jenkins, figuring I now have some grounding in the basics. Learned a lot about configuring for security along the way. Only other recommendations I have right now are on other topics, not CI/CD related.

Awesome, thx. I will do the tutorial, too, since I’m starting from zero knowledge, and I think if I install Jenkins anywhere it will be on a hosted/remote location, to make it more externally accessible, as @Halkeye noted.