如何通过几个步骤快速有效地建立专业的开发团队——案例研究
当前为公司创建和交付专用软件的趋势已大大促进了外包模式的发展。这是一个非常方便的解决方案,是因为客户(公司)不必再维持整个编程部门。相反,客户可以使用IT外包服务,并聘请专家来专业地交付成品。在这种解决方案中,消除了在培训自己的程序员、测试人员、分析师、甚至IT经理方面的投资问题。这是一种方便且灵活的方法。
客户迁移到 AWS 的意义之一就是包含SSO(单点登录),这是一个非常便利的解决方案。 快速查看(我们已拥有的功能)之后,发现我们能够使用ADFS。客户已经在使用ADFS进行其他服务,因此我们可以跳过说服安全团队的阶段。
花费数天挣扎于Ping Federate的错综复杂后,我们设法打开了SSO,并通过上述的 ADFS得到了一个很不错的重定向循环。 返回的SAML有我们所需的一切,Windchill 的答复是…… “错误500”。
对文档进行更深入的阅读后发现,Windchill支持ADFS SSO,但是基于从ADFS接收到的 SAML以创建新用户却不行。Windchill需要一个用户群来比对,通过使用某种类型的 ldap(使用SSL甚至更好)轮询域控制器提供最为便利。
将控制器公诸于世不太可能被安全团队所接受,但必须以某种方式对其进行轮询。
有必要与VPN客户端连接,并通过具有安全ldap的隧道轮询控制器。遗憾的是这并非易事,因为已经有一些环境在AWS中工作,每个都在不同的VPC中,每个都必须将其查询发送给AD。
有过很多选择(这仅是几个):
遗憾的是,已经存在的VPC与客户端在其网络中拥有的地址重叠。当然,有办法来克服这种情况,但是我们很急,在全球性组织中折腾路由可能要持续多年的时间
一段简短的演示(向客户突显问题),结果是决定创建一个新的VPC,在其他VPC之间执行路由和互联,连接VPN并在其上设置 VPC AWS Directory Service。
这就是我们所做的,不过遗憾的是,事实证明后者的局限性不允许对客户域中的对象进行ldap协议轮询。不可否认地,这是一个小小的挫折……更不用说必须在域之间建立信任关系了。
同时,为了不妨碍其他某些附加工具的开发,我们使用简单的SSH隧道在VPC中设置了标准的Amazon Linux,绕过了一些与AWS中缺少传输 VPC相关的限制。
另一种方法是以只读模式在AWS中公开客户的域控制器。这样的解决方案即使在VPN隧道存在问题的情况下也提供了对应用程序的访问。VPN的搭建异常顺利
我们以为已经很接近了:控制器是只读的,可以通过ldap进行轮询,且一切都进行得很顺利,但是之前同意该选项的客户安全却不行了。好吧,安全有自己的见解,并且不会提供内部CA公钥 — 经典的PKI
某种程度上带着情绪,我们决定适可而止吧。快速回顾一下事态:
类似于活动目录代理ldap的某种东西。我们使用VPN设置了VPC,通过ldap查询找到代理,然后顺利地将自身重定向到客户的AD,一切回到本垒。
再进行 5 个小时的测试和TAADAAM — 奏效了。OpenLDAP正在解决问题。在Windchill中进行验证,就这样。OpenLdap的EC2可以用,并且……基本上没什么好做的了。
嗯…将它放入Docker容器中如何?
嗯…在ECS中运行容器怎么样?
嗯…实际上并不需要持久存储,或许Fargate?
构建从LDAP代理到CentOS的容器一共也就是几行。然后可以创建到ECR的一个快速上传、任务的定义及服务。但是如何将流量导向到这项服务?毕竟,每次IP都会不同。也许通过 LoadBalancer? –不。
定义服务时,可以使用“服务发现”选项,该选项在Route53中创建一个托管区域并更新通向服务的A记录 — 漂亮。现在剩下要做的就是使用Windchill将托管区域固定到VPC,并以在那里注册的名称发起ldaps查询。
最后,(为了之后不必处理),所需要做的只是定义一个简单的健康检查,多亏ECS会在通常一分钟内将一个无法操作的容器换成新的容器。
让我们取得联系
联系我们