Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for session_server #92

Open
roock opened this issue Jul 5, 2019 · 14 comments · May be fixed by #432
Open

Add support for session_server #92

roock opened this issue Jul 5, 2019 · 14 comments · May be fixed by #432
Labels
enhancement 🆕 New feature or request work-in-progress Issue/PR is worked, should not become stale

Comments

@roock
Copy link
Contributor

roock commented Jul 5, 2019

It would be cool if we could support session_server in the gitlab runner config for interactive webterminals

https://docs.gitlab.com/ee/ci/interactive_web_terminal/index.html
https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section

@npalm
Copy link
Collaborator

npalm commented Jul 8, 2019

@roock cool idea, any idea thoughts for an implementation?

@npalm npalm added the enhancement 🆕 New feature or request label Jul 8, 2019
@roock
Copy link
Contributor Author

roock commented Jul 24, 2019

some thoughts:

  • we would need to aquire an static Elastic IP address
  • we could assign this IP with the following script: https://github.com/skymill/aws-ec2-assign-elastic-ip
  • we would need an additiona parameter to add a rule to the security group for allowing Gitlab to the websession port

@kayman-mk
Copy link
Collaborator

Oh yes, a feature I missed already. Guess no work is going on at the moment, right?

@npalm
Copy link
Collaborator

npalm commented Jul 24, 2020

Yep, no development is going on, feel free to create a PR

@kayman-mk
Copy link
Collaborator

The EIP is assigned to the runner agent. #124 will not be solved here.
I will also offer the possibility to add a rule to a load balancer instead of assigning an EIP.

@kayman-mk
Copy link
Collaborator

I reviewed my last comment and think that it makes no sense to add an IP or load balancer or something else. The reason is, that you should already been able to reach the runner from your gitlab instance (to start the build jobs).

@roock
Copy link
Contributor Author

roock commented Aug 25, 2020

I reviewed my last comment and think that it makes no sense to add an IP or load balancer or something else. The reason is, that you should already been able to reach the runner from your gitlab instance (to start the build jobs).

Afaik there is a difference between regular runner jobs and the session Server. For regular jobs, the runner will establish a http connection to the gitlab server. For the session server, Gitlab will establish a (tls-encrypted) connection to the runner, so you will need to expose the session service to Gitlab.

@kayman-mk
Copy link
Collaborator

kayman-mk commented Sep 4, 2020

Oh yes, you are absolutely right. I will add options for an IP address and a load balancer (ALB, ELB do not work here, see https://docs.gitlab.com/ee/administration/integration/terminal.html#enabling-and-disabling-terminal-support)

@roock
Copy link
Contributor Author

roock commented Sep 4, 2020

The module already supports adding an EIP directly to the instance. Not sure if it is strictly required to put it behind a ALB, although it might be a more elegant solution.

@kayman-mk
Copy link
Collaborator

@roock Yeah, just saw it. So nothing to do for the EIP. An ALB listener can now be passed to the module. But the test is still missing. The idea is to use either EIP or ALB. Depends on your preferences, company guidelines, ...

@kayman-mk
Copy link
Collaborator

Hm, still on my wishlist. Using an ALB is too complicated. Let's stick with the EIP solution which is already in place.

@kayman-mk
Copy link
Collaborator

Ok, let's give it another try. Stick with EIP for the base feature and add ALB support later.

@kayman-mk kayman-mk linked a pull request Jan 15, 2022 that will close this issue
@github-actions github-actions bot added the stale Issue/PR is stale and closed automatically label Jan 2, 2023
@kayman-mk kayman-mk removed the stale Issue/PR is stale and closed automatically label Jan 3, 2023
@github-actions github-actions bot added the stale Issue/PR is stale and closed automatically label Mar 19, 2023
@kayman-mk kayman-mk removed the stale Issue/PR is stale and closed automatically label Mar 19, 2023
@github-actions github-actions bot added the stale Issue/PR is stale and closed automatically label May 19, 2023
@kayman-mk kayman-mk removed the stale Issue/PR is stale and closed automatically label May 22, 2023
@github-actions github-actions bot added the stale Issue/PR is stale and closed automatically label Jul 22, 2023
@kayman-mk kayman-mk removed the stale Issue/PR is stale and closed automatically label Jul 27, 2023
@github-actions github-actions bot added the stale Issue/PR is stale and closed automatically label Sep 26, 2023
@kayman-mk kayman-mk removed the stale Issue/PR is stale and closed automatically label Sep 28, 2023
@kayman-mk kayman-mk added the work-in-progress Issue/PR is worked, should not become stale label Nov 9, 2023
@cattle-ops cattle-ops deleted a comment from github-actions bot Nov 12, 2023
@cattle-ops cattle-ops deleted a comment from github-actions bot Nov 12, 2023
@cattle-ops cattle-ops deleted a comment from github-actions bot Nov 12, 2023
@cattle-ops cattle-ops deleted a comment from github-actions bot Nov 12, 2023
@cattle-ops cattle-ops deleted a comment from github-actions bot Nov 12, 2023
@connorshea
Copy link

Was there any progress toward this? :)

@kayman-mk
Copy link
Collaborator

No progress at all. Any ideas?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 🆕 New feature or request work-in-progress Issue/PR is worked, should not become stale
Projects
None yet
4 participants