<p>Running Jenkins on EC2 is the better option. It's better to keep the functions that manage your containers separate from the containers themselves. I know this is different than Kubernetes, but this isn't Kubernetes. </p>

<p>Build an ELK Stack on EC2 as well and send your build logs to that instance so you can go through them when troubleshooting. It sounds like your setup is good with data volumes and such. I would recommend that you use Fargate instead of EC2 nodes for your workers though. Not clear which you are using. </p>

<p>There are simpler solutions than Jenkins as well. You may want to consider CircleCI, GitLab Runner, TeamCity, Bamboo, and others. Jenkins is made to do all things and is a good place to learn the process, but if an alternative does the job just as well and more easily, then try that. My current favorite is GitLab Runner. It's just simpler and it integrates your Git repo with the CI tool in addition to having its own image repo for you to use (in certain versions). </p>

<p>You can also give EKS a shot. I haven't tried it but Kubernetes is a superior product. It's far more complex, but definitely a better orchestration tool.</p>

CC BY-SA 4.0
2019-07-03T19:35:56.473Z
2019-07-03T19:35:56.473Z
amatusko
<p>There are other options- Containers on EC2 is what we do. A lot of people are not thrilled with ECS, and EKS is maturing as a better alternative, they say. </p>

<p>It's hard to really devopsify the current Jenkins, without treating the persistent configuration as a one big persistent filesystem. By the time you've installed jobs, and plugins, and credentials, and configuration you may as well just maintain the whole designated storage filesystem, back it up to S3, and attach it to the container as you docker run. This practice is independent of the container-orchestration choice.</p>

<p>Another problem that plagued us was/is maintaining build logs. Jenkins emails build logs in plain text, but I have yet to figure out how to ship them off to a filesystem where I can grep through them when debugging. Our current practice only keeps a few weeks worth. Maybe I missed something? Please correct me!</p>

<p>There is a new JenkinsX aimed at Kubernetes, but not ready as of Feb 2019.</p>

<p>That said, keeping your jobs as jenkinsfiles in GitHub works really well.</p>

CC BY-SA 4.0
2019-02-26T00:15:19.913Z
2019-02-26T00:15:19.913Z
John Fisher
<p>I am new to AWS, docker and jenkins. I want to run a jenkins build pipeline and I have tried using following two ways on AWS:</p>

<ol>
<li><p>Running jenkins inside the EC2 instance following the steps at this AWS <a href="https://d1.awsstatic.com/Projects/P5505030/aws-project_Jenkins-build-server.pdf" rel="nofollow noreferrer">link</a>. I created a new EC2 instance and installed jenkins inside the ec2 instance (ssh into the instance). I configured jenkins and ran a build pipeline successfully.</p></li>
<li><p>Running jenkins inside the ECS cluster following the steps at this <a href="https://docs.aws.amazon.com/aws-technical-content/latest/jenkins-on-aws/containerized-deployment.html#security-considerations-containerized-deployments" rel="nofollow noreferrer">AWS link</a>.  I created two container instances for Jenkins and data volume, jenkins is installed and running inside one of the instances. (I could not move ahead this point because I was unable to not find the initial password for jenkins)</p></li>
</ol>

<p>I could not find much information about the second process of containerized deployment on internet. As I am moving ahead in this process, I am unable to understand which process is better to run a build pipeline securely.</p>

<jenkins-pipeline><amazon-ec2><amazon-ecs>
Is containerized deployment of jenkins on ECS better than running jenkins inside EC2 instance to secure pipeline information?
bot
# Is containerized deployment of jenkins on ECS better than running jenkins inside EC2 instance to secure pipeline information?

(Asked by: username_0 on 2019-01-31)

I am new to AWS, docker and jenkins. I want to run a jenkins build pipeline and I have tried using following two ways on AWS:

1. Running jenkins inside the EC2 instance following the steps at this AWS [link](https://d1.awsstatic.com/Projects/P5505030/aws-project_Jenkins-build-server.pdf). I created a new EC2 instance and installed jenkins inside the ec2 instance (ssh into the instance). I configured jenkins and ran a build pipeline successfully.
2. Running jenkins inside the ECS cluster following the steps at this [AWS link](https://docs.aws.amazon.com/aws-technical-content/latest/jenkins-on-aws/containerized-deployment.html#security-considerations-containerized-deployments). I created two container instances for Jenkins and data volume, jenkins is installed and running inside one of the instances. (I could not move ahead this point because I was unable to not find the initial password for jenkins)

I could not find much information about the second process of containerized deployment on internet. As I am moving ahead in this process, I am unable to understand which process is better to run a build pipeline securely.

**Tags:** jenkins-pipeline, amazon-ec2, amazon-ecs


---

## 2 answers

### Answer by username_1 on 2019-07-03. Score: 2

Running Jenkins on EC2 is the better option. It's better to keep the functions that manage your containers separate from the containers themselves. I know this is different than Kubernetes, but this isn't Kubernetes.

Build an ELK Stack on EC2 as well and send your build logs to that instance so you can go through them when troubleshooting. It sounds like your setup is good with data volumes and such. I would recommend that you use Fargate instead of EC2 nodes for your workers though. Not clear which you are using.

There are simpler solutions than Jenkins as well. You may want to consider CircleCI, GitLab Runner, TeamCity, Bamboo, and others. Jenkins is made to do all things and is a good place to learn the process, but if an alternative does the job just as well and more easily, then try that. My current favorite is GitLab Runner. It's just simpler and it integrates your Git repo with the CI tool in addition to having its own image repo for you to use (in certain versions).

You can also give EKS a shot. I haven't tried it but Kubernetes is a superior product. It's far more complex, but definitely a better orchestration tool.


---

### Answer by username_2 on 2019-02-26. Score: 0

There are other options- Containers on EC2 is what we do. A lot of people are not thrilled with ECS, and EKS is maturing as a better alternative, they say.

It's hard to really devopsify the current Jenkins, without treating the persistent configuration as a one big persistent filesystem. By the time you've installed jobs, and plugins, and credentials, and configuration you may as well just maintain the whole designated storage filesystem, back it up to S3, and attach it to the container as you docker run. This practice is independent of the container-orchestration choice.

Another problem that plagued us was/is maintaining build logs. Jenkins emails build logs in plain text, but I have yet to figure out how to ship them off to a filesystem where I can grep through them when debugging. Our current practice only keeps a few weeks worth. Maybe I missed something? Please correct me!

There is a new JenkinsX aimed at Kubernetes, but not ready as of Feb 2019.

That said, keeping your jobs as jenkinsfiles in GitHub works really well.


---

