feat: Add support for session server

[kayman-mk]

trafficstars

Description

This feature allows you to open an interactive web terminal from your Gitlab job and run one-off commands in your CI pipeline. See Interactive Web Terminals.

The connection can be established via an EIP (use enable_eip = true) only.

Closes #92

Migrations required

No.

Verification

still missing

with no session_server

Gitlab Runner still working

with session_server

config.toml is valid There is a listener on the Gitlab Runner it is possible to connect to the specified port from localhost able to execute jobs from Gitlab

[npalm]

@kayman-mk I am not using this feature, can you give some direction to for testing / setting up. Or even provide an example. Great work!!!

[kayman-mk]

I will, yes. But yesterday I discovered some problems with the Runner when enabling the session_server. So I have to do some more checks before it is ready

By the way: Now it makes sense to place runners and executors in different subnets: Runners in public and Executors in a private one as Gitlab needs to establish a communication to the Runner.

[kayman-mk]

Not sure what's going on here. Deployed this branch, but if I place the Runner in my public subnet I am not able to connect via SSM and I do not see any logs in Cloudwatch. Really strange. May be there are some company restrictions in place. I have to check. Placing the Runner in a private subnet works. Configuration looks good and Gitlab shows the "Debug" button if a job is selected. Seems to be fine.

[kayman-mk]

@npalm If you deploy this branch, make sure that the Runner is placed in a public subnet and it's reachable from the Gitlab instance. Set the following variables

  enable_eip = true
  session_server = {
    timeout           = 1800
    port              = 8093
    gitlab_cidr_block = ["0.0.0.0/0"]
  }

If a job is assigned by this Runner you will notice a "Debug" button on the Gitlab job page. Pressing this button opens a terminal and you are connected to the Executor running the job.

[npalm]

Changes looks goot, tried to run a test but not working so far. Did not got the runners up on the public subnet. Need a bit more time to run some checks

[npalm]

@kayman-mk sorry for the late replies, will check the PR this weekend.

[npalm]

@kayman-mk should it be still in draft?

[kayman-mk]

As I have no idea what's wrong here, let's leave it in draft mode. I'll try to check with my AWS experts what's wrong with our subnets.

From my point of view the development is done here. Just need to check the deployed module.

[npalm]

Did you got it working?

[kayman-mk]

Still not working, but on my list ...

[github-actions[bot]]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This PR was closed because it has been stalled for 15 days with no activity.

[kayman-mk]

It seems that the session server can't be used with all executors. It might be the case that it is not working for docker+machine. Saw some comments on Stackoverflow.

[kayman-mk]

and just another ocmment: If you are using a reverse proxy with your GitLab instance, web terminals need to be enabled